Vorwort und Lese-Anleitung

Was ist HiveGrid 2.0?

HiveGrid 2.0 ist eine Software-Plattform für Handwerksbetriebe: speziell aufgesetzt für SHK-Betriebe (Sanitär, Heizung, Klima). Sie bündelt das, was heute typischerweise auf fünf bis sieben verschiedene Werkzeuge verteilt ist:

• CRM und Vertrieb (heute: HubSpot)
• Mitarbeiter-Kommunikation und HR (heute: Quiply)
• Bestands-ERP (heute: KWP, bleibt, wird angebunden)
• Workflow-Automatisierung (heute: Zapier, n8n, Supabase)
• Telefonie (heute: AirCall, bleibt, wird angebunden)
• Email und Kalender (heute: Google Workspace, bleibt, wird angebunden)
• Angebot und Signatur (heute: PandaDoc, bleibt, wird angebunden)

Geerkens ist der Erstkunde und Referenz-Partner für Phase 1. Die Plattform wird so gebaut, dass sie für Geerkens am Tag der Live-Schaltung wirklich produktiv nutzbar ist, und gleichzeitig modular genug, dass weitere SHK-Betriebe und später andere Gewerke (Maler, Elektro) darauf aufgenommen werden können.

Warum dieses Pflichtenheft?

Die letzten beiden Implementierungs-Anläufe sind an unscharfer Spezifikation gescheitert. Es gab eine Vision (97 Features, 18 Kategorien), aber keine vertragsfähige Detail-Beschreibung. Code wurde geschrieben, ohne dass klar war, welche Knöpfe es geben muss, welche Rollen welche Rechte haben, welche Fehlertexte angezeigt werden, was bei Doppel-Bearbeitung passiert.

Dieses Pflichtenheft schließt diese Lücke. Es dokumentiert für jedes der 35 Module in nummerierter, klar zitierbarer Form, was die Plattform können muss.

Wie liest man dieses Dokument?

Aufbau

Das Pflichtenheft besteht aus drei Hauptteilen:

1. Rahmen (Sie lesen ihn gerade): Vision, USP-Säulen, Architektur-Vorschriften, Anti-Liste, Glossar.
2. Module (Hauptteil): 35 Module, gruppiert in sieben Implementierungs-Blöcken. Pro Modul: Was es tut, warum es wichtig ist, alle wesentlichen Anforderungen in nummerierter Form, was bewusst NICHT in Phase 1 ist, Beispiele für Klartext-Fehlertexte.
3. Anhang: Geparkte Themen (Pricing, Migration), Verifikations-Workflow, Verweise auf die technischen Detail-Spezifikationen.

Nummerierungs-Schema

Jeder Punkt im Pflichtenheft hat eine eindeutige Adresse:

Beispiel: „M17.5.2" - M17 = Modul 17 (Automation Engine) - 5 = fünfter inhaltlicher Abschnitt im Modul - 2 = zweiter Punkt in diesem Abschnitt

So kann jeder Punkt bei der Durchsprache direkt benannt werden: „Bei M17.5.2 stimmt was nicht, wir brauchen das Limit anders."

Was bedeutet „Phase 1" und was nicht?

Phase 1 = das, was zum Cloud-Launch live ist und Geerkens produktiv nutzen kann. Auf diesem Pflichtenheft.

Phase 2 = nach erfolgreichem Geerkens-Launch, mit zahlenden Folge-Kunden. Kein Bestandteil dieses Vertrags.

Anti-Liste = explizit ausgeschlossen, auch nicht in Phase 2 (z. B. eigenes Rechnungs-Modul, Marketing-Plattform, eigene CMS-/Sites-Engine). Begründung pro Punkt unter Abschnitt „Was bewusst NICHT gebaut wird".

Was tun bei Unstimmigkeiten?

1. Punkt zitieren (z. B. „M04.6.3 ist mir zu eng").
2. Korrektur-Vorschlag dazu schreiben (Klartext, kein Layout).
3. Bis zur Sign-off-Runde sammeln, danach gehen Änderungen über die Change-Request-Liste (siehe Verifikations-Workflow im Anhang).

Glossar

Damit es bei der Durchsprache keine Begriffsverwirrung gibt:

Schnell-Übersicht: Die 35 Module in einem Satz

Vision, USP-Säulen und Anti-Liste

V.1 Produkt-Vision

HiveGrid 2.0 macht Mittelständler unabhängig von Software-Agenturen. Eine Handwerksfirma soll ihre wichtigsten betrieblichen Werkzeuge auf einer Plattform finden, und sie selbst pflegen können, ohne externes Beratungsbudget für jeden Kleinkram.

V.1.1 Eine Plattform statt sieben Werkzeuge. CRM, Vertrieb, Auftragsabwicklung, Mitarbeiter-Kommunikation, Telefonie, Email, Automatisierung, auf einer Oberfläche, mit gemeinsamer Nutzer-, Rechte- und Daten-Welt.

V.1.2 SHK fokussiert, anderes Gewerk vorbereitet. Inhalt zum Launch kompromisslos auf Sanitär/Heizung/Klima zugeschnitten. Architektur so gebaut, dass weitere Branchen (Maler, Elektro, ...) als Konfiguration ergänzt werden können, nicht als Code-Erweiterung.

V.1.3 Selbst-Wartbar. Automatisierungen, Templates, Pipelines kann der Geschäftsführer selbst (oder ein technisch interessierter Mitarbeiter) anlegen, ändern, abschalten, ohne Agentur-Termin.

V.1.4 Klartext statt Black-Box. Wenn etwas schiefgeht, sagt die Plattform in einem ganzen Satz, was los ist und was zu tun ist, keine Fehler-Codes, keine kryptischen Logs für den Endnutzer.

V.1.5 Komplett in Europa. Hosting (Scaleway), Datenbank, KI-Anbieter (Mistral, Scaleway, AlephAlpha), alles EU. DSGVO ist kein Anhang, sondern Bauprinzip.

V.2 Die drei USP-Säulen

Hier unterscheidet sich HiveGrid bewusst von HubSpot, Quiply und vergleichbaren Plattformen:

V.2.1 Automatisierungs-Engine als Klebstoff (Modul 17). Wenn-Dann-Regeln bauen ist auf großen Plattformen heute eher Pflicht-Übung. Bei HiveGrid ist die Automation-Engine der zentrale Bus, mit dem alle Module verzahnt werden.

V.2.2 KI als Bedien-Oberfläche der Automation (Modul 18 + 17). Statt „klicke dir Trigger zusammen" wird gesagt: „Wenn jemand das Kontaktformular ausfüllt und das Volumen über 10.000 EUR ist, schick mir eine Push und leg den Lead in der Premium-Pipeline an." Die KI baut das Wenn-Dann-Konstrukt, der Nutzer bestätigt es. Visuelles Editieren bleibt möglich, aber Erschaffen läuft über Sprache.

V.2.3 Saubere Anbindung an Bestands-ERPs über Adapter-Schicht (Modul 33a + 19). KWP ist nicht abgelöst, sondern eingebunden. Über die Apps-Engine als einheitliche Schnittstelle, Taifun, TopKontor, Streit V.1 (alle Phase 2) hängen sich später an dieselbe Schnittstelle, ohne dass Eingeweide umgebaut werden.

V.3 Was HiveGrid bewusst NICHT ist

Die folgenden Punkte sind explizit aus Phase 1 ausgeschlossen, teilweise aus jeder Phase. Das ist die wichtigste Disziplin-Liste dieses Pflichtenhefts. Jedes „Mitnehmen" eines Anti-Listen-Punktes muss als Change-Request ausdrücklich beauftragt werden (siehe Verifikations-Workflow im Anhang).

V.3.1 Komplett ausgeschlossen, auch in Phase 2 / 3

V.3.1.1 Eigene Webseiten / CMS / Blog / MySite. Marketing-Webseiten gehören nicht in HiveGrid. Die hivegrid.de-Marketing-Seite ist eine separate Sache. V.3.1.2 Versionierung von Angeboten (V1/V2/V3). PandaDoc kann das. V.3.1.3 Form-Verzweigungslogik / Form-Charts. Phase 1 Standard-Forms, kein Typeform-Klon. V.3.1.4 WhatsApp-Marketing. Rechtliche Grauzone und kein Geerkens-Pain. V.3.1.5 Sub-Workflows / Loops in Automation-Engine. Loop-Guard-Komplexität, später eventuell. V.3.1.6 Apple-Login. Würde nur unter Apple-Reviewer-Druck eingeführt. V.3.1.7 Google-OAuth-Login. Würde Apple-SIWA-Pflicht triggern. V.3.1.8 Custom-JS-Expressions in Automation-Conditions. Sicherheits-Risiko.

V.3.2 Ausgeschlossen aus Phase 1 (Phase 2 oder später)

V.3.2.1 Eigenes Rechnungs- und Buchhaltungs-Modul. KWP bleibt System-of-Record. Nach KWP-Geschäftsführer-Termin neu evaluieren. V.3.2.2 Buchhaltungs-Adapter (LexOffice, sevDesk, FastBill, Datev). Phase 2. V.3.2.3 WhatsApp-Inbox und Unified Inbox (Email + WhatsApp + weitere Messaging-Kanäle in einer Sicht pro Abteilung oder Projekt, Vorbild Superchat) [N15, 09.05.2026]. Phase 2. V.3.2.4 Knowledge Base / Internes Wiki. Phase 2. V.3.2.5 Bidirektionales Customer-Portal (Endkunde antwortet zurück). Phase 1: Endkunde sieht und lädt hoch, mehr nicht. V.3.2.5a Service-Modul (eigenständige Pipeline für Wartungen und Service-Einsätze, separat vom projekt-basierten Auftrags-Modul) [N9, 09.05.2026]. Phase 1 erkennt klar: Wartung und Service sind keine Projekte. In Phase 2 bekommt HiveGrid ein eigenes Service-Modul mit Service-Pipeline, Wartungs-Verträgen, Wiederkehr-Logik und Service-Ticket-Verwaltung. V.3.2.6 Multi-Portal-Branding für Customer-Portal. Phase 2. V.3.2.7 HiveMind als autonomer Agent (eigenständige KI-Aktionen ohne User-Trigger). Phase 1 nur KI-auf-User-Anforderung. Vertrauensgewinn aufbauen. V.3.2.8 Andere ERPs (Taifun, TopKontor, Streit V.1). Erst mit zahlendem Kunden auf der jeweiligen ERP. V.3.2.9 Sipgate-Telefonie. Phase 2. V.3.2.10 Hardware-Sicherheits-Schlüssel (FIDO2/WebAuthn) für 2-Faktor. Phase 2, Phase 1 nur TOTP-App. V.3.2.11 IP-Whitelisting, SAML / Single Sign-On. Enterprise-Funktionen, Phase 2. V.3.2.12 Custom-Subdomain pro Mandant. Nur Enterprise-Plan, Phase 2. V.3.2.13 Schreibendes Public-API. Phase 1 nur Lese-API + Webhooks. V.3.2.14 GraphQL-API. Phase 2. V.3.2.15 OAuth2-für-Drittanbieter (so dass externe Apps sich gegen HiveGrid authentifizieren). Phase 2. V.3.2.16 Branding voll: White-Label, Custom-Fonts, Email-Templates, Custom-Login. Phase 2. V.3.2.17 Community-App-Marketplace (M33b). Phase 2. V.3.2.18 Template-Marketplace (M33c). Phase 2. V.3.2.19 NFC, Bluetooth, andere advanced native Mobile-Features. Phase 2. V.3.2.20 Modul 8 (Rechnungs-UI in HiveGrid). Nach KWP-Termin neu evaluieren. V.3.2.21 Modul 16 (Knowledge Base / Wiki). Phase 2. V.3.2.22 Modul 40 (CMS / Sites / Blog). Komplett ausgeschlossen, auch Phase 2/3.

V.4 Was HiveGrid NICHT ablöst

V.4.1 KWP (ERP, Rechnungen, Lohn), bleibt System-of-Record für Geerkens. HiveGrid bindet an, ersetzt nicht. V.4.2 AirCall und HalloPetra (Telefonie), werden angebunden, nicht ersetzt. Andere Telefonie-Anbieter (Sipgate, Auerswald-PBX, weitere) ist Phase 2. V.4.3 Google Workspace (Email, Docs), Email-Sync läuft, Docs werden über Files-Modul referenziert. V.4.4 PandaDoc / DocuSign (Angebot + Signatur), wird angebunden.

V.5 Was HiveGrid bei Geerkens ersetzt

V.5.1 HubSpot: komplett (CRM, Lead, Sales-Pipeline, Booking, Email-Marketing). V.5.2 Quiply: komplett (HR-Hub, Mitarbeiter-Kommunikation). V.5.3 Zapier + n8n + Supabase: als Klebstoff. Eigene Automation-Engine ersetzt das Geflecht. V.5.4 Teile von Google Kalender: bleibt als Quelle, aber Termin-Verwaltung läuft über HiveGrid.

Architektur-Vorschriften (Querschnitt)

Diese 20 Vorschriften gelten modulübergreifend für die gesamte Plattform. Sie sind Bauprinzipien, nicht Funktionen, daher in einem eigenen Kapitel und nicht pro Modul wiederholt. Pro Modul wird in der jeweiligen Modul-Section verwiesen, welche Vorschriften besonders relevant sind.

A.1 Klartext-Diagnostik in jedem Feature

A.1.1 Jeder erkennbare Fehler-Zustand hat einen fest formulierten Klartext-Text und (wo sinnvoll) einen Lösungs-Knopf. Nicht „401 Unauthorized" sondern „Die Verbindung zur Buchhaltungs-Software ist abgelaufen, bitte einmal neu anmelden. [Anmelden]".

A.1.2 Keine KI-on-the-fly-Übersetzung von Fehlertexten in Phase 1. Texte sind redaktionell vorgefertigt, durchsuchbar, mehrsprach-fähig (über das i18n-Modul M30).

A.1.3 Kein Feature wird freigegeben, bevor die Klartext-Texte definiert und im Pflichtenheft des jeweiligen Moduls aufgeführt sind.

A.2 Adapter-Schicht für jede Integration

A.2.1 Externe Systeme (KWP, Gmail, AirCall, Legacy-Provider, PandaDoc, Calendar, ...) werden nur über die Apps-Engine (Modul 33a) angebunden, nie direkt aus einem Modul heraus.

A.2.2 Auch wenn aktuell nur eine konkrete Implementierung existiert (z. B. nur KWP als ERP), wird das Adapter-Interface so gebaut, dass weitere ERPs (Taifun, TopKontor) später ohne Engine-Umbau dazu kommen.

A.2.3 Verbindungs-Status, Sync-Jobs und Klartext-Diagnostik sind über alle Apps einheitlich: gleiche Anzeige, gleiche Bedien-Logik.

A.3 Branchen-Templates deklarativ, nicht hartkodiert

A.3.1 Standard-Pipelines (Sales, Auftrag), Standard-Rollen, Standard-Automatisierungen pro Branche werden in Konfigurations-Dateien abgelegt, nicht als Code.

A.3.2 Onboarding-Wizard liest aus diesen Konfigurationen. Eine neue Branche bedeutet: Konfigurations-Datei dazu, keine Code-Änderung.

A.3.3 Phase 1: SHK pre-selected. Andere Branchen sichtbar als „Coming soon".

A.4 Mehrsprachigkeit von Anfang an sauber vorbereitet

A.4.1 Kein einziger UI-Text wird hartkodiert. Alle Texte kommen aus Sprach-Dateien (Locale-Files).

A.4.2 Phase 1: nur Deutsch befüllt. Phase 2: DeepL-Pipeline für DE → EN/TR/PL.

A.4.3 Sprach-Wechsel pro Nutzer (nicht pro Mandant), ein deutscher Mitarbeiter und ein türkischer Mitarbeiter im selben Mandanten sehen unterschiedliche Sprachen.

A.5 Berechtigungs-Logik als Standard, nicht als Sonderfall

A.5.1 Jede Liste, jede Suche, jede Detail-Ansicht filtert automatisch nach den Berechtigungen des angemeldeten Nutzers. Ein Nutzer ohne Lese-Recht auf Modul X sieht es nicht im Menü, kann es nicht aufrufen, taucht nicht in der Suche auf.

A.5.2 Owner-Check für „eigene Daten" (z. B. Vertriebler darf nur seine eigenen Verkaufsfälle sehen): wird zentral implementiert, nicht pro Modul nachgebaut.

A.5.3 Es gibt keine versteckten URL-Tricks, mit denen man Berechtigungen umgehen kann.

A.6 Audit-Log als Default

A.6.1 Jede schreibende Aktion (Anlegen, Ändern, Löschen, Status-Wechsel) wird mit Wer, Wann, Was, Vor-/Nach-Wert ins Audit-Log geschrieben (Modul 21).

A.6.2 Das gilt auch für Aktionen, die durch Automatisierungen oder durch externe Sync-Vorgänge ausgelöst werden, der Auslöser wird mit-protokolliert.

A.7 Feature-Flags als Standard-Einführungs-Hülle

A.7.1 Neue Features werden hinter einem Feature-Flag eingeführt (Modul 32), erst für interne Tests, dann für ausgewählte Mandanten, dann breit ausgerollt.

A.7.2 Bricht etwas, schaltet der Plattform-Admin den Flag aus, ohne Deploy.

A.8 Idempotenz pro Automatisierungs-Aktion

A.8.1 Jeder Schritt einer Automatisierung hat einen Idempotenz-Schlüssel: wird derselbe Schritt zweimal ausgeführt (z. B. nach einem Retry), wird die Aktion nicht doppelt durchgeführt.

A.8.2 Konkret: keine doppelten Mails, keine doppelten Datensätze, keine doppelten KWP-Push-Operationen.

A.9 Anti-Liste und Change-Request-Mechanismus

A.9.1 Was nicht im Pflichtenheft steht, ist nicht beauftragt. Punkt.

A.9.2 Jede Erweiterung nach Sign-off geht über die Change-Request-Liste, mit Datum, Zustimmungs-Vermerk und Auswirkung auf Zeitplan/Aufwand.

A.9.3 Kein stillschweigendes Mitnehmen in Phase 1 („Wir hatten doch besprochen ...").

A.10 Vorschau und Rückgängig für KI-Aktionen

A.10.1 Eine KI-erzeugte Automatisierung wird nie direkt scharfgeschaltet: immer Vorschau mit konkreter Auswirkung („würde 1.400 Personen betreffen, hier die ersten 5: ...") und User-Bestätigung.

A.10.2 24-Stunden-Rückgängig-Fenster für die Wirkungen einer Automatisierung, innerhalb 24h können angelegte Datensätze, Status-Änderungen, Tag-Änderungen rückgängig gemacht werden. Versendete Mails sind nicht zurückziehbar, aber die Empfänger-Liste ist sichtbar.

A.11 Schema-Drift-Sentinel für ERP-Anbindungen

A.11.1 Tägliche Prüfung gegen die KWP-Datenbank: existieren erwartete Tabellen, Spalten, Datentypen noch?

A.11.2 Bei Abweichung: Push-Alarm an Plattform-Admin (uns), bevor Geerkens den Bruch live merkt.

A.12 EU-Stack komplett

A.12.1 Hosting: Scaleway (Frankreich, Niederlande). A.12.2 Datenbank: in EU. A.12.3 KI-Anbieter: ausschließlich EU. Mistral (primär), Scaleway-Hosted-Modelle (sekundär), AlephAlpha (tertiär). Kein Anthropic, kein OpenAI. A.12.4 Trade-off bewusst: Modell-Qualität ist nicht GPT-5-Niveau, ist aber für unsere Anwendungsfälle ausreichend. Marketing-Argument: „100 % EU, 100 % DSGVO".

A.13 Multi-Provider-Fallback für KI

A.13.1 Wenn der primäre KI-Anbieter ausfällt (Mistral 30 Min nicht erreichbar), wird automatisch auf den zweiten umgeschaltet.

A.13.2 Wenn alle KI-Anbieter ausfallen: KI-getriebene UI-Elemente zeigen Klartext-Hinweis und Fallback-Modus („Bitte nutze den visuellen Editor stattdessen").

A.13.3 Deterministische KI-Antworten (gleiche Frage → gleiche Antwort) werden gecacht.

A.14 Promptfoo-Eval-Suite mit Injection-Vektoren

A.14.1 Jeder neue KI-Prompt-Flow wird mit einer Test-Suite (Promptfoo) gegen Standard-Injection-Vektoren geprüft.

A.14.2 Continuous Integration, nicht einmaliger Build-Test.

A.14.3 Bösartige Eingaben (Form-Submission, Email-Inhalt) werden niemals direkt als Anweisung an die KI weitergereicht.

A.15 Optimistic Locking + Last-Write-Wins-mit-Sichtbarkeit für ERP-Sync-Konflikte

A.15.1 Wenn jemand in HiveGrid eine Auftrag bearbeitet, während Sandra ihn parallel in KWP ändert: System erkennt den Versions-Konflikt beim Speichern und zeigt einen Diff-View zur Auflösung.

A.15.2 Wenn das nicht erkannt wurde (z. B. weil die Bearbeitung in KWP nicht gemeldet ist): Last-Write gewinnt, aber der Überschreiber bekommt eine Klartext-Notification mit Restore-Knopf.

A.16 Rate-Limit + Anomalie-Erkennung für Automatisierungs-Trigger

A.16.1 Hartes Limit: pro Mandant max. 1.000 Trigger pro Stunde (konfigurierbar). Rest wird verworfen mit Notification.

A.16.2 Anomalie-Erkennung: wenn Trigger-Rate plötzlich 10× über dem Normalwert liegt, wird die Automatisierung pausiert mit Klartext-Hinweis: „Diese Automatisierung wurde 2.000-mal in 5 Minuten ausgelöst, typisch sind 5-10 pro Tag. Wir haben sie pausiert. Bitte prüfen."

A.17 Schleifen-Schutz mit Klartext-Stopp und Pre-Save-Validierung

A.17.1 Hartes Limit: max. 5 Auto-Trigger pro Datensatz pro 60 Sekunden. Danach Abbruch.

A.17.2 Bei Abbruch: visuelle Darstellung der Trigger-Kette und Klartext-Hinweis: „Automatisierung A löst B aus, B löst A aus, Schleife erkannt, beide pausiert."

A.17.3 Pre-Save-Validierung beim Erstellen: System prüft Abhängigkeits-Graph beim Speichern und warnt vor potenziellen Schleifen.

A.18 Heartbeat und Auto-Wiederherstellung für ERP-Sync-Programme

A.18.1 Das Sync-Programm beim Kunden vor Ort (heute: kwpsync.exe) sendet alle 5 Minuten ein Lebenszeichen an HiveGrid.

A.18.2 Bleibt das Lebenszeichen 15 Minuten aus: Alarm an Plattform-Admin und Sandra (Geerkens).

A.18.3 Sync-Programm läuft als Windows-Dienst (mit NSSM-Wrapper), automatischer Neustart bei Absturz, automatischer Start nach Reboot.

A.19 Persistente Warteschlange mit Zeitstempeln und Rate-begrenztes Wiedereinspielen

A.19.1 Wenn HiveGrid 6 Stunden ausfällt, sammelt das Sync-Programm vor Ort alle Operationen in einer lokalen Warteschlange (SQLite, unbegrenzte Größe).

A.19.2 Beim Wiederhochfahren: chronologisches Wiedereinspielen, max. 100 Operationen pro Minute (Rate-Limit), sichtbarer Fortschritts-Indikator.

A.19.3 Bei Konflikten zwischen Warteschlange und HiveGrid-Stand: Klartext-Konflikt-Anzeige, Nutzer entscheidet welcher Stand gilt.

A.20 Aktions-Grenze für KI: keine schreibenden Aktionen aus externen Quellen ohne Bestätigung

A.20.1 Die KI darf aus RAG-Kontext (Suche in eigenen Daten) oder aus externen Daten (eingehende Email, Form-Submission) niemals direkt schreibende Aktionen (Email senden, Datensatz anlegen, Stage ändern) ableiten.

A.20.2 Eine solche Aktion muss immer durch eine separate User-Bestätigung gehen, auch wenn die KI sicher ist.

A.20.3 Phase-1-Regel zur Vertrauensbildung. Wird in Phase 2 (autonome Agents) eventuell gelockert.

Block 1: Plattform-Fundament

Diese fünf Module bilden die Basis, auf der alle anderen Module aufsetzen: Anmeldung, Mandanten-Trennung, Rollen, Mehrsprachigkeit, Branding, Feature-Schalter und der Plattform-Admin-Bereich für den HiveGrid-Betreiber selbst.

Modul 27: Anmeldung, Mandanten und Rollen

Was es tut: Stellt sicher, dass jede Handwerksfirma ihren eigenen, abgeschotteten Arbeitsbereich (Mandant) hat, dass sich nur berechtigte Personen anmelden können und dass jeder Mitarbeiter genau die Funktionen sieht, die zu seiner Rolle passen. Löst ab: Login-Logik in HubSpot, Quiply, Zapier-Workspaces, Supabase-Eigenbau-Auth. Warum es wichtig ist: Ohne saubere Mandanten-Trennung ist die Plattform DSGVO-untauglich und nicht verkaufbar. Ohne klare Rollen sieht jeder Monteur Vertriebsdaten und jeder Vertriebler die Personalakten.

27.1 Mandanten-Anlage (= eine Handwerksfirma legt einen Workspace an)

27.1.1 Es gibt zwei Wege, einen Mandanten anzulegen: Selbstbedienung (Firma registriert sich selbst auf der Webseite) oder durch HiveGrid manuell (nach einem Verkaufsgespräch). 27.1.2 Bei der Selbstbedienung muss das Anmelde-Formular folgende Angaben verlangen: Email, Passwort, Firmenname, Vor- und Nachname, Branche, Firmengröße (Mitarbeiter-Spanne als Auswahl), Zustimmung zu AGB, Datenschutz und Auftragsverarbeitungsvertrag. 27.1.3 Optionale Angaben sind: Telefonnummer für Support und Umsatzsteuer-Identifikationsnummer für Rechnungen. 27.1.4 Aus dem Firmennamen wird automatisch ein eindeutiger Web-Adressbestandteil (z. B. „geerkens-gmbh") erzeugt. Dieser Adressbestandteil muss vom Nutzer noch im Anmelde-Formular geändert werden können. 27.1.5 Der Adressbestandteil wird live auf Eindeutigkeit geprüft. Bei Konflikt wird ein Vorschlag mit Nummer angeboten. 27.1.6 Nach Anlage ist der Adressbestandteil nicht mehr änderbar (sonst werden Lesezeichen ungültig). Eine spätere Migration ist nur durch HiveGrid-Support möglich. 27.1.7 In Phase 1 ist nur SHK als Branche aktiv wählbar; andere Branchen erscheinen als „Demnächst verfügbar".

27.2 Strikte Mandanten-Trennung (= keine Firma sieht Daten einer anderen)

27.2.1 Das System muss durchgehend verhindern, dass ein Mitarbeiter einer Firma jemals Daten einer anderen Firma sehen, ändern oder löschen kann, auch nicht durch URL-Manipulation, fehlerhafte Suchanfragen oder Fehler in einzelnen Funktionen. 27.2.2 Die Trennung gilt auch für hochgeladene Dateien (Fotos, Dokumente) und für zwischengespeicherte Daten, niemals werden Inhalte zweier Firmen vermischt abgelegt. 27.2.3 Auch automatisch laufende Hintergrund-Prozesse (z. B. nächtliche Auswertungen, Email-Versand) müssen den Mandanten-Bezug explizit setzen, damit keine Vermischung passiert. 27.2.4 Eine Person kann Mitglied in mehreren Mandanten sein (z. B. der Geschäftsführer hat einen Test-Mandant und einen Echt-Mandant). Beim Wechsel zwischen Mandanten gibt es eine sichtbare Umschalt-Funktion, die in der gesamten App erreichbar ist. 27.2.5 Bei der Anmeldung landet der Nutzer im zuletzt genutzten Mandanten. Wer zwei oder mehr Mandanten hat, sieht beim ersten Login eine Auswahl-Seite.

27.3 Anmeldung am System

27.3.1 Standardweg ist Email + Passwort. 27.3.2 Passwörter müssen mindestens 12 Zeichen lang sein. Es werden keine Sonderzeichen-Zwangsregeln verlangt, stattdessen wird das Passwort gegen eine Liste bekannt geleakter Passwörter geprüft. Bei Treffer Klartext-Hinweis: „Dieses Passwort wurde in einem bekannten Datenleck gefunden, bitte ein anderes wählen." 27.3.3 Alternativ kann sich ein Nutzer per „Magischem Anmelde-Link" einloggen: System schickt ihm eine Email mit einem Link, der 15 Minuten gültig ist und einmal genutzt werden kann. 27.3.4 Microsoft-Anmeldung („mit Microsoft anmelden") ist Phase 2. 27.3.5 Bei zu vielen Fehlversuchen (5 in 15 Minuten) wird das Konto für 15 Minuten gesperrt. Ab dem dritten Fehlversuch wird zusätzlich ein Bilderrätsel zur Bot-Abwehr eingeblendet. 27.3.6 Beim Setzen eines neuen Passworts werden alle laufenden Anmeldungen auf allen Geräten beendet.

27.4 Zwei-Faktor-Authentifizierung (= zweiter Sicherheitsfaktor)

27.4.1 Als zweiter Faktor wird ausschließlich eine Authenticator-App (Google Authenticator, Authy, 1Password etc.) unterstützt. Keine SMS, SMS gilt als unsicher. 27.4.2 Bei der Einrichtung werden 10 einmalig nutzbare Notfall-Codes erzeugt, die der Nutzer ausdrucken oder im Passwort-Manager speichern soll. 27.4.3 Für Mandanten-Administratoren ist der zweite Faktor verpflichtend; für andere Mitarbeiter ist er optional. Der Mandanten-Administrator kann jedoch im Mandanten einstellen: „Zweiter Faktor für alle Mitarbeiter Pflicht", Mitarbeiter ohne werden bei der nächsten Anmeldung dazu gezwungen. 27.4.4 Es gibt eine Funktion „Auf diesem Gerät 30 Tage merken", damit der zweite Faktor nicht jedes Mal abgefragt wird. Vertrauenswürdige Geräte sind in den persönlichen Einstellungen einzeln widerrufbar. 27.4.5 Verliert ein Mitarbeiter seine Notfall-Codes, kann der Mandanten-Administrator den zweiten Faktor zurücksetzen (mit Eintrag im Protokoll). Verliert ein Mandanten-Administrator als einziger seine Zugänge, kann der HiveGrid-Support helfen.

27.5 Sitzungs-Verwaltung (= aktive Anmeldungen)

27.5.1 Eine Anmeldung bleibt standardmäßig 30 Tage aktiv (gleitendes Fenster); der Mandanten-Administrator kann diese Dauer für seinen Mandanten kürzer einstellen. 27.5.2 Nach 4 Stunden Inaktivität muss erneut bestätigt werden (sanfter Refresh, ggf. zweiter Faktor). 27.5.3 Jeder Nutzer sieht in seinen Sicherheits-Einstellungen alle aktiven Anmeldungen mit Gerät, Browser, ungefährem Standort und letzter Aktivität, mit der Möglichkeit, einzelne oder alle Anmeldungen zu beenden. 27.5.4 Bei einer Passwort-Änderung, einer Email-Änderung, einer 2FA-Änderung oder einer Deaktivierung des Nutzers werden alle aktiven Anmeldungen automatisch beendet.

27.6 Wer darf was: Rollen und Berechtigungen

27.6.1 Jeder Mitarbeiter hat eine oder mehrere Rollen. Die Rolle bestimmt, welche Funktionen er in der App sieht und nutzen darf. 27.6.2 Berechtigungen werden in Stufen pro Funktionsbereich vergeben (z. B. „im Bereich CRM: kein Zugriff / nur eigene sehen / alle sehen / eigene anlegen und bearbeiten / alles dürfen inkl. Einstellungen"). Eine erweiterte Ansicht erlaubt feinere Einstellungen pro Einzel-Berechtigung. 27.6.3 Beim Anlegen eines neuen SHK-Mandanten werden 7 Standard-Rollen automatisch eingerichtet: Geschäftsführer, Vertriebsleiter, Vertriebler, Projektleiter / Bauleiter, Büro / Backoffice, Marketing, Monteur. 27.6.4 Diese 7 Rollen sind nur Vorlagen, der Mandanten-Administrator kann sie umbenennen, ändern, löschen oder neue eigene Rollen anlegen. 27.6.5 Eine Person kann mehrere Rollen gleichzeitig haben; die Rechte addieren sich. 27.6.6 Pro Rolle ist hinterlegt, ob sie standardmäßig die „Büro-Oberfläche" (Desktop-orientiert) oder die „Baustellen-Oberfläche" (mobil-vereinfacht) sieht. Der einzelne Mitarbeiter kann das auf seinem Gerät überschreiben. 27.6.7 Der Mandanten-Administrator kann sich nicht selbst die Administrator-Rechte entziehen, wenn er der Einzige mit dieser Rolle ist.

27.7 Standard-Rollen-Übersicht (Phase 1, SHK) [N1, 09.05.2026]

27.7.1 Diese 10 Rollen sind die SHK-Standard-Vorlage. Der Mandanten-Administrator kann sie umbenennen, anpassen, löschen oder eigene Rollen anlegen (siehe 27.6.4).

27.8 Gruppen (= organisatorische Einteilung ohne Berechtigungs-Wirkung)

27.8.1 Zusätzlich zu Rollen kann der Mandanten-Administrator Gruppen anlegen (z. B. „Team Süd", „Außendienst", „Festangestellte"). 27.8.2 Gruppen vergeben in Phase 1 keine Rechte. Sie werden für Filter, Massen-Zuweisungen, Benachrichtigungen und Automatisierungs-Bedingungen genutzt. 27.8.3 Eine Person kann in mehreren Gruppen sein. Beim Löschen einer Gruppe mit Mitgliedern erscheint ein Hinweis.

27.9 Mitarbeiter einladen, deaktivieren, entfernen

27.9.1 Der Mandanten-Administrator lädt neue Mitarbeiter per Email ein. Er wählt Email, Rolle (Pflicht) und optional Gruppen, Name und persönliche Nachricht. 27.9.2 Der Eingeladene erhält eine Email mit einem Einladungs-Link, der 7 Tage gültig ist. 27.9.3 Wenn die Email noch nicht im System bekannt ist, legt der Eingeladene ein neues Konto an. Wenn er schon einen Account hat (z. B. von einem anderen Mandanten), wird er beim Klick automatisch Mitglied dieses Mandanten. 27.9.4 Ein Mitarbeiter kann vorübergehend deaktiviert werden (kommt nicht mehr rein, kann aber jederzeit wieder aktiviert werden) oder dauerhaft entfernt werden (Beziehung gelöscht, Wieder-Aufnahme nur per neuer Einladung). 27.9.5 Vor jeder Deaktivierung oder Entfernung muss das System prüfen, ob dem Mitarbeiter noch Aufgaben, Vertriebsfälle, Projekte oder Termine zugeordnet sind. Es muss eine Massen-Umverteilungs-Funktion und eine Einzel-Umverteilungs-Funktion geben. Daten ohne neue Zuweisung zu lassen ist nur mit ausdrücklicher Bestätigung möglich. 27.9.6 Der letzte Mandanten-Administrator kann nicht entfernt werden. Sich selbst entfernen ist nicht möglich.

27.10 Konto-Löschung (Datenschutz- und Apple-Pflicht) [N2, 09.05.2026]

27.10.1 Jeder Nutzer kann sein Konto in den persönlichen Einstellungen löschen. 27.10.2 Der Lösch-Vorgang ist mehrstufig: Erklärungs-Schritt (was wird gelöscht, was bleibt anonymisiert, was bleibt aus rechtlichen Gründen), Identitäts-Bestätigung (Passwort + zweiter Faktor), Sonderfall-Prüfung (ist der Nutzer einziger Mandanten-Administrator?, dann blockieren mit Hinweis) und finaler Bestätigungs-Klick mit 3-Sekunden-Zwangs-Wartezeit. 27.10.3 Nach Löschung werden persönliche Daten (Name, Email, Avatar) entfernt; Verknüpfungen in alten Aufträgen bleiben mit dem Hinweis „ehemaliger Mitarbeiter". 27.10.4 Innerhalb von 24 Stunden nach Lösch-Bestätigung kann der HiveGrid-Support die Löschung rückgängig machen, falls jemand das Konto nicht freiwillig gelöscht hat. 27.10.5 Wenn ein Nutzer sein Konto löscht, bekommt der Mandanten-Administrator eine Benachrichtigung (Push, Email, In-App) mit Name, Datum, Zeitpunkt und Hinweis auf bereits umverteilte oder noch offene Daten. So bleibt der Mandant immer informiert. 27.10.6 Der Mandanten-Administrator kann jeden Nutzer seines Mandanten auch selbst löschen, ohne dass dieser einwilligen muss. Der Vorgang läuft über dieselben Stufen (Erklärung, Daten-Umverteilung, Bestätigung) und wird im Audit-Log mit „durch Admin gelöscht" vermerkt. Der gelöschte Nutzer erhält eine Email-Mitteilung über die Löschung.

27.11 Mandanten-Lebenszyklus (= was passiert mit dem Mandanten über die Zeit)

27.11.1 Mögliche Zustände eines Mandanten: Test-Phase, Bezahlend, Zahlung gescheitert, Pausiert, Vom Betreiber gesperrt, Kündigung läuft, Gelöscht. 27.11.2 Bei gescheiterter Zahlung wird der Mandant zunächst nur lesend (kein Schreiben, kein Email-Versand, keine Automatisierung) und nach 30 Tagen ohne Zahlung in den Kündigungs-Lauf gestellt. 27.11.3 Der Mandanten-Administrator kann seinen Mandanten freiwillig pausieren (reduzierte Gebühr, Workspace nur lesend, jederzeit reaktivierbar), z. B. saisonale Betriebsruhe. 27.11.4 Bei Kündigung gibt es eine 30-Tage-Karenzphase, in der die Kündigung zurückgezogen werden kann. Nach 30 Tagen erfolgt die endgültige Löschung. 27.11.5 Pro Zustand muss ein Klartext-Banner im Mandanten sichtbar sein, das den Status erklärt und die nächste Handlung anbietet.

27.12 Schnittstellen-Schlüssel (= API-Keys für externe Verbindungen)

27.12.1 Im Mandanten können Schnittstellen-Schlüssel erstellt werden, mit denen externe Systeme (z. B. Make, n8n, Zapier-Reste, eigene Tools) Daten an HiveGrid liefern oder abfragen. 27.12.2 Pro Schlüssel werden Name, erlaubter Umfang (nur lesen / nur eingehende Webhooks / volles Lesen / Automatisierungen auslösen), Erstellungs-Datum, letzte Nutzung und Status angezeigt. 27.12.3 Ein Schlüssel ist nach Erstellung nur einmal sichtbar (Sicherheits-Standard). Der Nutzer wird in Klartext gewarnt, ihn zu kopieren. 27.12.4 Schlüssel laufen nach 365 Tagen ab (Zwangs-Rotation). Sie gehören dem Mandanten, nicht dem einzelnen Nutzer (überdauern Mitarbeiter-Wechsel). 27.12.5 Standardmäßig sind 1.000 Anfragen pro Stunde erlaubt. Der Mandanten-Administrator kann das erhöhen. 27.12.6 Pro Schlüssel werden die letzten 100 Anfragen mit Endpunkt, Status und Zeit angezeigt, zur Fehlersuche.

27.13 Funktions-Freischaltung pro Tarif (= Feature-Gates)

27.13.1 Jeder Mandant hat ein Abo (siehe Modul 28), das bestimmt, welche Module verfügbar sind. 27.13.2 Wenn ein Nutzer auf eine Funktion klickt, die im aktuellen Tarif nicht enthalten ist, erscheint ein Klartext-Hinweis: „Die Funktion ‚X‘ ist im Tarif ‚Y‘ verfügbar. Mehr erfahren auf hivegrid.de/pricing." Der Link führt aus der App heraus auf die Marketing-Seite (Apple-Vorgabe). 27.13.3 Konkrete Tarife und Preise werden in Modul 28 definiert. Modul 27 stellt nur die technische Möglichkeit, Funktionen pro Mandant zu sperren oder freizugeben.

27.14 Bewusst NICHT in Phase 1

27.14.1 Microsoft-Anmeldung („Login mit Microsoft"), verschoben auf Phase 2. 27.14.2 Eigene Domain pro Mandant (z. B. „crm.geerkens.de"), nur für Enterprise-Tarif in Phase 2. 27.14.3 Massen-Einladung per CSV-Datei, Phase 2. 27.14.4 Hardware-Sicherheits-Schlüssel (FIDO2/WebAuthn) als zweiter Faktor, Phase 2. 27.14.5 Mandanten-Eigenservice-Schalter für Beta-Funktionen (siehe Modul 32), Phase 2.

27.15 Klartext-Fehlertexte (Beispiele)

27.15.1 Falsches Passwort: „Email oder Passwort stimmt nicht. Noch X Versuche, dann wird das Konto kurz gesperrt." 27.15.2 Konto gesperrt: „Konto temporär gesperrt, Support kontaktieren." 27.15.3 Magic-Link abgelaufen: „Dieser Anmelde-Link ist abgelaufen oder wurde bereits genutzt. Bitte einen neuen anfordern." 27.15.4 2FA-Code falsch: „Code stimmt nicht. Achte darauf, dass die Uhr deines Geräts genau geht." 27.15.5 Berechtigung fehlt: „Diese Aktion ist mit deiner Rolle nicht möglich. Bitte deinen Mandanten-Administrator ansprechen." 27.15.6 Kontingent-Konflikt beim Löschen: „Diese Person hat noch 12 offene Aufgaben und 3 laufende Projekte. Bitte vorher umverteilen." 27.15.7 Konto-Löschung blockiert: „Du bist einziger Administrator in 1 Mandant. Bitte vorher einen anderen Administrator bestimmen."

Modul 30: Mehrsprachigkeit

Was es tut: Sorgt dafür, dass die gesamte Plattform sprachlich austauschbar ist, Phase 1 läuft alles auf Deutsch, in Phase 2 sollen weitere Sprachen ohne Neu-Programmierung dazukommen können. Löst ab: Manuelle Übersetzungs-Bastelei in alten Tools. Warum es wichtig ist: Geerkens hat polnische Monteure und türkische Kunden. Mehrsprachigkeit ist ein Verkaufsargument, das bei Konkurrenz-Tools oft fehlt. Wenn man es von Anfang an sauber baut, kostet eine neue Sprache später fast nichts.

30.1 Grundprinzip

30.1.1 Es darf an keiner Stelle der App Text geben, der direkt im Programmcode festgeschrieben ist. Jeder sichtbare Satz, jeder Knopf-Text, jede Fehlermeldung wird aus zentralen Sprach-Dateien geladen. 30.1.2 Ganze Sätze werden als Ganzes übersetzt, nicht aus Bruchstücken zusammengebaut. Sonst lassen sie sich in anderen Sprachen nicht sinnvoll formulieren (z. B. ist die Wortstellung im Polnischen anders). 30.1.3 Mehrzahl-Formen (1 Aufgabe / 5 Aufgaben) werden über ein Standard-Format gelöst, das auch Sprachen mit komplexeren Mehrzahl-Regeln unterstützt (Polnisch hat drei Mehrzahl-Formen). 30.1.4 Datums-, Uhrzeit- und Zahlen-Formate folgen automatisch der Sprache des Nutzers; Standard ist deutsche Schreibweise. 30.1.5 Eine Bau-Prüfung verhindert, dass versehentlich harte Texte in den Code rutschen, der Build schlägt fehl, wenn ein nicht erlaubter harter Text gefunden wird. 30.1.6 In Phase 1 wird ausschließlich Deutsch gepflegt; Englisch, Türkisch, Polnisch sind als Ziel-Sprachen vorgesehen, aber noch nicht befüllt.

30.2 Sprache des Nutzers und des Mandanten

30.2.1 Jeder Nutzer hat eine persönliche Sprach-Einstellung in seinem Profil. 30.2.2 Jeder Mandant hat eine Standard-Sprache (z. B. Deutsch), die der Mandanten-Administrator setzt. 30.2.3 Jeder Kontakt im CRM hat eine Sprach-Angabe, diese wird für ausgehende Emails an den Kontakt verwendet. 30.2.4 Welche Sprache wirklich angezeigt wird, entscheidet sich in dieser Reihenfolge: persönliche Einstellung des angemeldeten Nutzers, sonst Mandanten-Standard, sonst Browser-Sprache (für nicht angemeldete Besucher), sonst Deutsch. 30.2.5 Bei ausgehenden Mitteilungen entscheidet die Sprache des Empfängers: Mitarbeiter-Sprache, sonst Kontakt-Sprache, sonst Mandanten-Standard, sonst Deutsch.

30.3 Was ist Plattform-Text und was ist Mandanten-Text

30.3.1 Plattform-Texte (Knöpfe, Menü-Punkte, Hinweise, Email-Vorlagen von HiveGrid) werden vom System übersetzt. 30.3.2 Mandanten-Inhalte (eigene Pipeline-Stufen-Namen, Kennzeichnungen, Zusatzfeld-Beschriftungen, Formular-Texte, Marketing-Email-Inhalte) gibt der Mandant in seiner Arbeitssprache ein und werden auch genau so angezeigt, eine automatische Übersetzung der Mandanten-Inhalte ist nicht Phase 1. 30.3.3 Der Mandant kann seine Mandanten-Inhalte in Phase 1 also nur in einer Sprache pflegen. Zwei-Sprach-Pipelines, Zwei-Sprach-Formulare etc. sind Phase 2.

30.4 Sprachwechsel

30.4.1 Der Nutzer kann seine Sprache jederzeit in seinen Einstellungen wechseln; die Änderung wirkt sofort ohne Neuladen. 30.4.2 Auf öffentlichen Seiten (Hilfe-Center, Buchungsseiten, Formulare für Endkunden) gibt es einen Sprach-Wähler, dessen Auswahl in einem Cookie gemerkt wird.

30.5 Bewusst NICHT in Phase 1

30.5.1 Aktive Übersetzung weiterer Sprachen (Englisch, Türkisch, Polnisch), kommt in Phase 2 über DeepL-Pipeline mit Glossar für Fach-Begriffe. 30.5.2 Automatische Chat-Übersetzung („polnischer Monteur schreibt Polnisch, Büro liest Deutsch"), Phase 2, ist aber bereits eingeplant als KI-Killer-Funktion. 30.5.3 Mehrsprachige Mandanten-Inhalte (Pipeline-Stufen in zwei Sprachen, Formular-Felder mehrsprachig), Phase 2. 30.5.4 Mehrsprachiges Hilfe-Center, Phase 2.

30.6 Klartext-Hinweise

30.6.1 Wenn ein Nutzer eine Sprache wählt, die noch nicht vollständig befüllt ist, wird automatisch auf Deutsch zurückgefallen. Im Mandanten-Admin gibt es dazu den Hinweis: „Die Sprache [X] ist noch nicht vollständig verfügbar. Bestehende Texte fallen auf Deutsch zurück." 30.6.2 Sprache erfolgreich gewechselt: „Sprache geändert."

Modul 31: Branding und Design (Hell/Dunkel-Modus)

Was es tut: Stellt sicher, dass jeder Nutzer wählen kann, ob er die App im hellen oder dunklen Design sehen will, und schafft die technische Grundlage dafür, dass in Phase 2 Mandanten ihr eigenes Logo, ihre eigenen Farben und (bei Enterprise) ihre eigene Domain bekommen können. Warum es wichtig ist: Ein dunkles Design ist heute Standard-Erwartung. Eigenes Branding ist ein Verkaufsargument für Enterprise-Kunden und stärkt die Marken-Wahrnehmung beim Endkunden im Kunden-Portal.

31.1 Hell/Dunkel-Modus pro Nutzer (Phase 1)

31.1.1 Jeder Nutzer kann in seinen Einstellungen zwischen drei Optionen wählen: „System" (folgt der Einstellung des Geräts), „Hell", „Dunkel". 31.1.2 Standard für neue Nutzer ist „System". 31.1.3 Die Auswahl wirkt sofort, ohne Neuladen der Seite. 31.1.4 Wenn der Nutzer „System" gewählt hat und die Geräte-Einstellung wechselt während die App offen ist (z. B. der Mac wechselt abends automatisch in den Dunkel-Modus), soll die App live mit umschalten. 31.1.5 Beim ersten Laden darf kurzzeitig nicht das falsche Design erscheinen (kein „Aufblitzen" der weißen Seite, wenn der Nutzer Dunkel-Modus eingestellt hat). Die Vorauswahl wird per Cookie gemerkt. 31.1.6 In der mobilen App (Capacitor) müssen auch Status-Leiste und Splash-Screen das gewählte Design respektieren.

31.2 Phase 1 enthält bewusst NICHT

31.2.1 Logo-Upload pro Mandant, Phase 2. 31.2.2 Eigene Farben pro Mandant (Primärfarbe, Akzentfarben), Phase 2. 31.2.3 Mandanten-Name-Überschreibung in der Anzeige (eigener Anzeige-Name statt „HiveGrid"), Phase 2. 31.2.4 Tenant-Verwaltungsseite für Branding (/admin/branding/), Phase 2.

31.3 Phase-2-Vorhaben (Standard-Branding für alle Tarife)

31.3.1 Mandanten-Administrator kann Logo hochladen (PNG oder SVG, maximale Größe definiert). 31.3.2 Farb-Picker für Primärfarbe und 1-2 Akzentfarben mit Live-Vorschau. 31.3.3 Mandanten-Anzeige-Name kann den System-Standard überschreiben. 31.3.4 Branding wird angewendet auf: Seiten-Logo, Email-Kopfzeilen an Endkunden, Kunden-Portal, Anmelde-Seite des Mandanten, mobile App-Splash-Screen. 31.3.5 Marketing-Emails (Modul 10) übernehmen das Branding standardmäßig, jeweils einzeln überschreibbar. 31.3.6 Vor dem Live-Schalten kann der Mandanten-Administrator eine Vorschau sehen. 31.3.7 Reset-Funktion auf Standard.

31.4 Phase-2-Vorhaben (Vollständiges White-Label, nur Enterprise-Tarif)

31.4.1 Eigene Domain (z. B. „crm.geerkens.de") statt der HiveGrid-Standard-Adresse. 31.4.2 Eigene Schriftarten (Webfonts oder Google-Fonts). 31.4.3 Vollständig anpassbares Farb-Schema (alle Farb-Variablen, nicht nur Primär- und Akzentfarbe). 31.4.4 Eigene Email-Vorlagen (HTML, vom Mandanten gestaltet). 31.4.5 HiveGrid-Branding (Footer, „Powered by"-Hinweise) komplett entfernbar. 31.4.6 Domain-Verifizierung und automatische Zertifikats-Verwaltung im Hintergrund.

31.5 Berechtigungen

31.5.1 Hell/Dunkel-Modus ist persönliche Einstellung, keine Berechtigung nötig. 31.5.2 Phase 2: Mandanten-Branding nur für Mandanten-Administrator (gesonderte Berechtigung „Branding verwalten"). 31.5.3 Phase 2: White-Label-Funktionen sind nur im Enterprise-Tarif aktiv (über Tarif-Freischaltung, Modul 28).

Modul 32: Funktions-Schalter (Feature-Flags)

Was es tut: Gibt HiveGrid (= dem Software-Betreiber) ein internes Werkzeug, um neue Funktionen für einzelne Mandanten oder Mandanten-Gruppen gezielt ein- oder auszuschalten, zum Testen, schrittweisen Ausrollen oder Abschalten alter Funktionen. Warum es wichtig ist: Verhindert, dass eine fehlerhafte neue Funktion sofort allen Kunden Probleme macht. Erlaubt Pilot-Tests bei einzelnen Kunden (z. B. Geerkens als Erstkunde sieht eine Beta zuerst). Ist die technische Voraussetzung für „Feature wird im Hintergrund gebaut, aber niemand sieht es bis es fertig ist".

32.1 Was ist ein Funktions-Schalter

32.1.1 Ein Funktions-Schalter ist ein zentraler An/Aus-Schalter im Code, der zur Laufzeit entscheidet, ob ein bestimmtes Stück Software für einen bestimmten Mandanten sichtbar/aktiv ist. 32.1.2 Mandanten sehen in Phase 1 keine eigene Bedien-Oberfläche für Schalter, sie merken nur, dass Funktionen sichtbar sind oder nicht. Die Schalter werden ausschließlich von HiveGrid im internen Plattform-Admin verwaltet.

32.2 Pflicht-Angaben pro Schalter

32.2.1 Pro Schalter wird gespeichert: technischer Name (eindeutig), Klartext-Bezeichnung, Beschreibung (was tut der Schalter, welcher Code-Bereich, welches Modul), Standard-Wert (an oder aus, falls keine Sonderregel greift), Lebenszyklus-Stufe, Verantwortlicher Plattform-Admin, Modul-Tag. 32.2.2 Lebenszyklus-Stufen: „Beta" (für einzelne Test-Mandanten), „Roll-out" (breit ausgerollt, in Beobachtung), „Allgemein verfügbar" (immer an, Code-Aufräumung steht an), „Abgekündigt" (wird entfernt).

32.3 Drei Wege, einen Schalter zu setzen

32.3.1 Standard-Wert: gilt für alle Mandanten, solange keine speziellere Regel greift. 32.3.2 Filter-Regel: trifft Mandanten nach Eigenschaften, z. B. „alle Mandanten mit über 50 Mitarbeitern", „alle SHK-Mandanten", „Mandanten erstellt nach 1. März 2026", „diese 5 Test-Mandanten namentlich". 32.3.3 Direkte Mandanten-Ausnahme: für einen einzelnen Mandanten den Schalter auf An oder Aus setzen, überstimmt Filter und Standard-Wert. Optional mit Notiz („Manuell aktiviert für Geerkens-Pilot") und optionalem Ablauf-Datum.

32.4 Auswertungs-Reihenfolge (was gewinnt)

32.4.1 Existiert eine direkte Ausnahme für einen Mandanten, gewinnt diese. 32.4.2 Sonst werden alle aktiven Filter geprüft (sortiert nach Priorität); der erste passende Filter setzt den Wert. 32.4.3 Sonst gilt der Standard-Wert des Schalters.

32.5 Verwaltungs-Oberfläche (nur HiveGrid-intern)

32.5.1 Liste aller Schalter mit technischem Namen, Klartext-Bezeichnung, Lebenszyklus-Stufe, Standard-Wert, Anzahl aktiver Filter, Anzahl Einzel-Ausnahmen, Verantwortlichem, Modul-Tag, letzter Änderung. 32.5.2 Filter-Funktionen nach Lebenszyklus-Stufe, Modul-Tag, Verantwortlichem; Suche über Name und Bezeichnung. 32.5.3 Detail-Ansicht eines Schalters mit allen oben genannten Stamm-Daten plus: Liste der Filter, Liste der Einzel-Ausnahmen, Wirkungs-Statistik („X Mandanten haben den Schalter aktuell aktiv, Y nicht"), Änderungs-Historie. 32.5.4 Filter-Editor mit Live-Vorschau: „Mit dieser Bedingung wären aktuell 12 Mandanten betroffen, Liste anzeigen?" 32.5.5 Ausnahme-Editor mit Mandanten-Suche und optionalem Ablaufdatum. 32.5.6 Massen-Funktion: 12 Mandanten gleichzeitig auf denselben Wert setzen. 32.5.7 Lebenszyklus-Stufen wechselbar mit Bestätigungs-Dialog und Klartext-Hinweis auf Folgen. 32.5.8 Archiv-Funktion für Schalter, die nicht mehr genutzt werden, aber deren Spur bleibt.

32.6 Wer darf was im Plattform-Admin

32.7 Protokoll (Nachvollziehbarkeit)

32.7.1 Jede Änderung an einem Schalter, an einem Filter, an einer Einzel-Ausnahme wird mit Vorher/Nachher-Vergleich, Akteur, Zeitstempel und optionalem Begründungs-Text gespeichert. 32.7.2 Die Historie ist im Detail des Schalters einsehbar und im plattformweiten Audit-Bereich durchsuchbar.

32.8 Bewusst NICHT in Phase 1

32.8.1 Schalter pro einzelnem Nutzer (statt nur pro Mandant), Phase 2. 32.8.2 Selbstbedienung für Mandanten („Beta-Funktionen anzeigen"-Schalter im Mandanten), Phase 2. 32.8.3 Schalter mit mehr als zwei Werten (für A/B/C-Tests), Phase 2. 32.8.4 Prozentualer Roll-out („aktiviere für 25 % der Mandanten"), Phase 2. 32.8.5 Zeitgesteuerte Aktivierung („ab 1. Juni 2026 automatisch an"), Phase 2. 32.8.6 Nutzungs-Telemetrie pro Schalter, Phase 2.

32.9 Klartext-Hinweise

32.9.1 Schalter im Code referenziert, aber nicht angelegt: „Funktions-Schalter ‚X‘ ist nicht definiert, bitte im Admin-UI anlegen oder Code-Referenz korrigieren." (im Test-System sichtbarer Fehler, in der Live-Umgebung nur Protokoll-Eintrag). 32.9.2 Filter ohne Bedingung: „Dieser Filter würde alle Mandanten treffen, sicher gewollt?" 32.9.3 Filter wirkungslos durch höhere Priorität: „Dieser Filter ist wirkungslos, weil Filter ‚X‘ mit höherer Priorität dieselbe Mandanten-Menge erreicht." 32.9.4 Ausnahme mit Ablauf-Datum in der Vergangenheit: „Ablauf-Datum liegt in der Vergangenheit, die Ausnahme wird beim nächsten Aufräum-Lauf entfernt."

Modul 37: Plattform-Admin (= unser eigener Bedien-Bereich für HiveGrid)

Was es tut: Eigene, völlig getrennte Verwaltungs-Welt für uns als Software-Betreiber, auf einer eigenen Web-Adresse, mit eigenen Konten, eigenem Login, eigenen Berechtigungen. Hier verwalten wir Mandanten, Abos, Funktions-Schalter, Sicherheits-Protokolle, unsere eigenen Verkaufs-Kontakte und Support-Anfragen. Löst ab: Diverse Eigenbau-Werkzeuge, Notion-Tabellen, Spreadsheet-Listen für interne Verwaltung. Warum es wichtig ist: Ohne diesen Bereich kann HiveGrid die Plattform nicht professionell betreiben. Strikte Trennung zur Mandanten-Welt ist Sicherheits- und Datenschutz-Pflicht: Was wir als Betreiber tun, läuft nie über die Mandanten-Seite, damit der Schaden bei einem Sicherheits-Vorfall begrenzt bleibt und unsere Aktionen separat dokumentiert sind.

37.1 Strikte Trennung zur Mandanten-Welt

37.1.1 Der Plattform-Admin läuft auf einer eigenen Web-Adresse („admin.hivegrid.de"), die nicht mit der Mandanten-App („app.hivegrid.de") vermischt wird. 37.1.2 Plattform-Admin-Konten sind eigenständig, sie sind keine normalen Mitarbeiter eines Mandanten. Es gibt keinen Wechsel-Pfad zwischen den Welten ohne erneute Anmeldung. 37.1.3 Sitzungen (Cookies) der Plattform-Admin-Welt sind technisch von denen der Mandanten-Welt getrennt. 37.1.4 Wenn ein Plattform-Admin Mandanten-Daten ansieht, geschieht das durchgehend über dieselben Schutz-Mechanismen wie ein Mandanten-Mitarbeiter, kein Generalschlüssel, kein Umgehen der Mandanten-Trennung. 37.1.5 Schreibende Aktionen auf Mandanten-Daten sind streng begrenzt auf bestimmte vorgesehene Vorgänge (Status ändern, Test-Phase verlängern, Notiz anlegen, Lösch-Workflow im Auftrag anstoßen). Freies Bearbeiten der Mandanten-Daten ist nicht möglich.

37.2 Anmeldung am Plattform-Admin

37.2.1 Anmeldung ist ausschließlich per Email + Passwort. Keine Magic-Links (zu hohes Risiko bei Email-Account-Übernahme). 37.2.2 Zweiter Faktor (Authenticator-App) ist Pflicht für jeden Plattform-Admin, kein Opt-Out. 37.2.3 Bei 5 Fehlversuchen in 15 Minuten: 15 Minuten Sperre. Bilderrätsel ab 3. Fehlversuch. 37.2.4 Bei 10 Fehlversuchen in 24 Stunden: Konto wird gesperrt; nur ein anderer Super-Admin kann es entsperren. 37.2.5 Anmeldungs-Sitzungen laufen nach 8 Stunden ab (kürzer als bei Mandanten-Mitarbeitern). Inaktivitäts-Timeout: 1 Stunde. 37.2.6 Bei Wechsel der IP-Adresse mitten in der Sitzung wird Neu-Anmeldung verlangt. 37.2.7 „Auf diesem Gerät 30 Tage merken" steht hier nicht zur Verfügung, jede Anmeldung verlangt zweiten Faktor. 37.2.8 Der erste Plattform-Admin wird einmalig per Skript angelegt (kein öffentliches Anmelde-Formular).

37.3 Rollen im Plattform-Admin

37.3.1 Es gibt eigene Rollen, die unabhängig von den Mandanten-Rollen sind. 37.3.2 Standard-Rollen beim Anlegen: Super-Admin (alles), Support (lesender Zugriff plus Ticket-Bearbeitung), Vertrieb (Lead- und Verkaufs-Pipeline-Verwaltung), Engineering (Metriken, Funktions-Schalter, System-Aktionen), Betrachter (nur Lesen). 37.3.3 Rollen sind beliebig anpassbar. 37.3.4 Der letzte Super-Admin kann sich nicht selbst die Rechte entziehen oder sich selbst deaktivieren.

37.4 Bereiche im Plattform-Admin (Übersicht)

37.4.1 Dashboard mit Plattform-Kennzahlen. 37.4.2 Mandanten-Verwaltung. 37.4.3 Mandanten-Mitarbeiter-Verwaltung (alle Mitarbeiter aller Mandanten). 37.4.4 Plattform-Admin-Verwaltung (unsere eigenen Konten und Rollen). 37.4.5 Abo-Verwaltung (Anbindung an Legacy-Provider). 37.4.6 Funktions-Schalter (siehe Modul 32). 37.4.7 System-Gesundheit (Server, Hintergrund-Aufgaben, KWP-Sync). 37.4.8 Plattform-weites Audit-Protokoll. 37.4.9 Lead- und Verkaufs-Pipeline für unsere eigenen HiveGrid-Verkäufe. 37.4.10 Support-Anfragen-Posteingang. 37.4.11 Datenschutz-Verwaltung (Auftragsverarbeiter-Liste, Vertrags-Versionen). 37.4.12 Persönliche Einstellungen.

37.5 Dashboard: was wir auf einen Blick sehen

37.5.1 Anzahl Mandanten gesamt mit Trend (Vergleich zum Vormonat) und Aufteilung nach Status (Test-Phase, Bezahlend, Zahlung gescheitert, Pausiert, Gesperrt, Kündigung läuft). 37.5.2 Neue Mandanten letzte 7/30 Tage. 37.5.3 Wiederkehrender Monatsumsatz aktuell, Trend über 12 Monate, neue Umsätze, verlorene Umsätze, Zusatz-Umsätze des letzten Monats; Durchschnittsumsatz pro Mandant. 37.5.4 System-Status: grün/gelb/rot mit Klartext bei Auffälligkeit, Hintergrund-Aufgaben-Stau, Fehler-Quote letzte 24 Stunden, KWP-Sync-Gesundheit. 37.5.5 Aktivität: aktive Mandanten-Mitarbeiter letzte 24 Stunden / 7 Tage; Top 5 Mandanten nach Aktivität. 37.5.6 Unsere eigene Verkaufs-Pipeline: Anzahl Leads pro Status, Pipeline-Volumen. 37.5.7 Support: offene Tickets, ältester offener, durchschnittliche Lösungszeit. 37.5.8 Klick auf jede Kachel öffnet den entsprechenden Bereich. 37.5.9 Zeitraum-Wechsler (24 Stunden / 7 Tage / 30 Tage / 12 Monate).

37.6 Mandanten-Verwaltung

37.6.1 Liste aller Mandanten mit Name, Kennung, Status, Tarif, Monatsumsatz, Erstellungs-Datum, Anzahl Mitarbeiter, letzter Aktivität, Branche, Größe, zuständigem Plattform-Admin. 37.6.2 Filter und Suche, Sortierung, Spalten-Konfiguration, Massen-Aktionen (Kennzeichnung setzen, einem Plattform-Admin zuweisen, Email-Versand für Pflicht-Mitteilungen). 37.6.3 Detail-Ansicht eines Mandanten mit Stamm-Daten, Kontakt-Infos, Liste der Mandanten-Administratoren, Aktivitäts-Indikatoren, Abo-Details, Test-Phase-Info, Funktions-Schalter-Auswertung, Auftragsverarbeitungs-Vertrags-Status, internen Notizen, Aktivitäts-Protokoll. 37.6.4 Möglichkeit, den Status zu ändern (sperren, entsperren, pausieren), jede Änderung verlangt einen Pflicht-Begründungs-Text, der dauerhaft im Protokoll bleibt. 37.6.5 Test-Phase verlängern (Datum + Begründung). 37.6.6 Abo-Konditionen manuell überschreiben (für Enterprise-Sonder-Verträge). 37.6.7 Notizen anlegen, kategorisieren, anpinnen. 37.6.8 Funktions-Schalter pro Mandant setzen (siehe Modul 32). 37.6.9 Email an Mandanten-Administrator(en) versenden (Vorlage oder freier Text). 37.6.10 Daten-Export im Auftrag des Mandanten anstoßen. 37.6.11 Lösch-Workflow im Auftrag anstoßen (vermittelt, der Mandanten-Administrator bestätigt am Ende per Email-Link).

37.7 Stellvertreter-Anmeldung („Als Mandanten-Mitarbeiter einloggen")

37.7.1 Plattform-Admin kann sich für Support-Zwecke kurzzeitig als Mandanten-Mitarbeiter anmelden (z. B. um einen gemeldeten Fehler nachzuvollziehen). 37.7.2 Vor jeder Stellvertreter-Anmeldung ist ein Begründungs-Text Pflicht (z. B. „Bug-Reproduktion Ticket 123"). 37.7.3 Die Stellvertreter-Sitzung läuft maximal 30 Minuten. 37.7.4 Während der Stellvertreter-Anmeldung sehen die anderen Mandanten-Mitarbeiter im Mandanten ein gut sichtbares Banner: „Plattform-Support hat sich gerade als [Name] eingeloggt, Ticket [Nummer]". 37.7.5 Die volle Begründung wird im Protokoll dauerhaft gespeichert. Eine spezielle Berechtigung „Stellvertreter-Anmeldung" ist nötig.

37.8 Mandanten-Mitarbeiter-Verwaltung (alle Mitarbeiter aller Mandanten)

37.8.1 Liste mit Email, Name, Anzahl Mandanten-Mitgliedschaften, letzter Aktivität, 2FA-Status, Erstellungs-Datum, Status. 37.8.2 Detail-Ansicht mit Stamm-Daten, allen Mandanten-Mitgliedschaften und Rollen, aktiven Sitzungen, letzten Anmeldungen, vertrauenswürdigen Geräten, Audit-Spur, Lösch-Status. 37.8.3 Mögliche Aktionen: zweiten Faktor zurücksetzen (mit Begründung), Sitzungen beenden, Email ändern, Mitarbeiter deaktivieren/reaktivieren, Konto-Löschung im Auftrag, Wiederherstellung innerhalb der 24-Stunden-Karenz.

37.9 Plattform-Admin-Verwaltung (unsere eigenen Konten)

37.9.1 Liste aller Plattform-Admins mit Email, Rollen, Status, 2FA-Status, letzter Anmeldung, aktiven Sitzungen. 37.9.2 Plattform-Admin anlegen (Email, Name, Anfangs-Rolle), der Eingeladene bekommt einen Einrichtungs-Link mit verpflichtender 2FA-Einrichtung. 37.9.3 Rolle ändern, deaktivieren, zweiten Faktor zurücksetzen (durch anderen Super-Admin), Sitzungen beenden.

37.10 Abo-Verwaltung

37.10.1 Liste aller Abos mit Mandant, Tarif, Monatsumsatz, Status, Verlängerungs-Datum, Legacy-Provider-Sync-Status. 37.10.2 Detail-Ansicht mit Legacy-Provider-Verknüpfungen (Direkt-Link zum Legacy-Provider-Dashboard), aktuellem Tarif, Sitz-Anzahl (Büro + Monteur), Test-Phase, Rechnungs-Historie, Notizen über manuelle Sonder-Konditionen. 37.10.3 Mögliche Aktionen: Legacy-Provider-Abgleich erzwingen, Tarif manuell überschreiben (Enterprise-Sonderpreise mit Begründungs-Pflicht), Test-Phase verlängern, manuelle Rechnung anstoßen, Abo kündigen, Rückzahlung anstoßen. 37.10.4 Wenn die Daten in HiveGrid und in Legacy-Provider auseinanderlaufen, wird das im Detail mit Klartext-Vergleich angezeigt.

37.11 System-Gesundheit

37.11.1 Status pro Dienst (Web, API, Hintergrund-Aufgaben, Plan-Job-System, Datenbank, Zwischenspeicher, Datei-Speicher) mit Verfügbarkeit, Antwort-Zeiten, Fehler-Quote. 37.11.2 Hintergrund-Aufgaben-Bereich mit Liste aller Warteschlangen (Automatisierung, Email-Versand, KWP-Sync, Datenschutz-Export …), Status (in Arbeit, wartend, fehlgeschlagen, abgeschlossen), Möglichkeit fehlgeschlagene Aufgaben erneut zu starten oder Warteschlangen zu pausieren. 37.11.3 KWP-Sync-Bereich pro Mandant mit Heartbeat-Status, letztem erfolgreichem Sync, Fehler-Anzahl, Schema-Drift-Hinweisen, Möglichkeit zum Neu-Anstoßen. 37.11.4 Fehler-Anzeige mit den 10 häufigsten Fehlern der letzten 24 Stunden und Klick auf Detail.

37.12 Plattform-weites Audit-Protokoll

37.12.1 Liste aller Plattform-Admin-Aktionen plus Zugriff auf alle internen Mandanten-Audit-Protokolle in zusammengeführter Sicht. 37.12.2 Pro Eintrag: Datum, Akteur (Plattform-Admin, Mandanten-Mitarbeiter, System), Mandanten-Bezug, Aktions-Typ, Klartext-Zusammenfassung, Vorher/Nachher-Vergleich (in Detail-Schublade). 37.12.3 Filter: Akteur, Mandant (mit Auto-Vervollständigung), Aktions-Typ, Zeitraum, Ziel-Art. 37.12.4 Volltext-Suche in den Klartext-Zusammenfassungen. 37.12.5 Audit-Einträge sind unveränderlich, keine Bearbeitung, keine Löschung. 37.12.6 Aufbewahrungs-Frist: 24 Monate Standard. 37.12.7 Export für Compliance-Anfragen (CSV/JSON).

37.13 Eigene Lead- und Verkaufs-Pipeline (für UNSERE HiveGrid-Verkäufe)

37.13.1 HiveGrid hat eine eigene, vom Mandanten-CRM strikt getrennte Lead-Liste. Hier landen Anfragen von Handwerksbetrieben, die HiveGrid kaufen wollen. 37.13.2 Lead-Eingang: über Marketing-Formular auf der Webseite, Demo-Buchung, manuelle Anlage, eingehende Email, Empfehlung, Partner. 37.13.3 Pro Lead werden gespeichert: Name, Email, Telefon, Firma, Branche, Größe, Quelle, Quellen-Detail (Freitext z. B. „LinkedIn-Kampagne Mai 2026"), Status (neu, qualifiziert, kontaktiert, Demo geplant, Angebot raus, gewonnen, verloren, Spam), zugeordneter Plattform-Admin, Verlustgrund, Notizen. 37.13.4 Aktivitäts-Strom pro Lead: Email gesendet/empfangen, Anruf, Demo gehalten, Angebot raus, Notiz, Status-Wechsel, Zuweisung geändert. 37.13.5 Verkaufs-Pipeline (Kanban-Ansicht) mit den Stufen: Erstgespräch, Demo, Angebot, Verhandlung, Gewonnen, Verloren. Pro Karte: Lead-Name, Firma, geschätzter Jahresumsatz, Verantwortlicher, geplantes Abschluss-Datum. 37.13.6 Drag&Drop zwischen Stufen. 37.13.7 Bei „Gewonnen" gibt es eine Funktion „Zu Mandant promoten", die direkt in die manuelle Mandanten-Anlage führt und am Ende den Lead mit dem neu angelegten Mandanten verknüpft.

37.14 Manuelle Mandanten-Anlage und Test-Phase-Verlängerung

37.14.1 Für Demo-Vorbereitung, Enterprise-Onboarding nach Vertrag oder Lead-Promotion können wir Mandanten manuell anlegen. 37.14.2 Eingaben: Mandanten-Name + Kennung (mit Live-Prüfung), Branche, Größe, Erst-Administrator (Email + Name; bestehender Account oder neue Anlage), Anfangs-Tarif, Test-Phase-Dauer (Standard 7 Tage), optional Demo-Daten provisionieren, Begründung (Pflicht, warum manuelle Anlage). 37.14.3 Bestätigung legt Mandant an, Erst-Administrator bekommt Einrichtungs-Email mit Magic-Link. 37.14.4 Test-Phase-Verlängerung: neues End-Datum + Begründung; Klartext-Hinweis im Mandanten: „Test-Phase wurde bis [Datum] verlängert von [Plattform-Admin] mit Grund: [Text]."

37.15 Support-Bereich

37.15.1 Drei Wege, wie ein Support-Ticket entsteht: Klick im Mandanten auf einen Feedback-Knopf, eingehende Email an „support@hivegrid.de" (automatisch zugeordnet), manuelle Anlage durch einen Plattform-Admin nach Anruf oder Chat. 37.15.2 Ticket-Eigenschaften: Betreff, Mandanten-Bezug (falls bekannt), Mitarbeiter-Bezug, Quelle, Status (offen, in Arbeit, wartet auf Nutzer, gelöst, geschlossen), Priorität (niedrig, normal, hoch, dringend), zugewiesener Plattform-Admin, frei wählbare Kennzeichnungen. 37.15.3 Ticket-Detail mit Konversation, Verlinkung auf Mandant und Mitarbeiter, Aktivitäts-Protokoll. 37.15.4 Antworten werden als Email an den Mitarbeiter geschickt und erscheinen im Mandanten als interne Benachrichtigung. 37.15.5 Interne Notizen sind möglich (nur für Plattform-Admins sichtbar). 37.15.6 Standard-Antwort-Vorlagen können genutzt werden.

37.16 Datenschutz-Verwaltung

37.16.1 Auftragsverarbeiter-Liste (alle externen Dienste, die Mandanten-Daten verarbeiten): anlegen, bearbeiten, archivieren. Bei Änderung: automatische Email-Benachrichtigung an alle Mandanten-Administratoren mit 14-Tage-Widerspruchs-Frist (Datenschutz-Pflicht). 37.16.2 Auftragsverarbeitungs-Vertrags-Versionen: neue Version anlegen (PDF-Vorlage hochladen, Aktiv-ab-Datum, Beschreibung der Änderungen), Re-Akzeptanz-Aufforderung an alle Mandanten auslösen, Übersicht über Akzeptanz-Stände.

37.17 Bewusst NICHT in Phase 1

37.17.1 KI-Generations-Protokoll (Token-Verbrauch pro Mandant), Phase 2. 37.17.2 Zentrale Hilfe-Center-Artikel-Pflege im Plattform-Admin, Phase 2. 37.17.3 Vollständiger Helpdesk-Workflow mit SLA und Eskalations-Stufen, Phase 2. 37.17.4 Marketing-Automatisierung für Test-Phasen-Konvertierung, Phase 2. 37.17.5 Eigene Domain pro Mandant (Verwaltung im Plattform-Admin), Phase 2. 37.17.6 Cohorten-Analyse, Churn-Vorhersage, Phase 2. 37.17.7 Plattform-API für interne Automatisierung, Phase 2. 37.17.8 Hardware-Sicherheits-Schlüssel als zweiter Faktor für Plattform-Admins, Phase 2.

37.18 Klartext-Hinweise (Beispiele)

37.18.1 Status-Wechsel ohne Begründung: „Bitte Begründung angeben, wird im Audit-Log dauerhaft gespeichert." 37.18.2 Stellvertreter-Anmeldung ohne Begründung: blockiert, gleicher Hinweis. 37.18.3 Sonder-Tarif: „Diese Konditionen weichen vom Standard-Plan ab. Legacy-Provider wird nicht angepasst, manuelle Rechnungs-Erstellung erforderlich. [Verstanden, fortfahren]" 37.18.4 Doppelte Plattform-Admin-Email: „Diese Email gehört bereits zu einem Plattform-Admin ‚X‘, bitte direkt diesen verwalten." 37.18.5 Letzter Super-Admin: „Du bist der einzige Super-Admin. Rechte-Entzug nicht möglich. Bitte zuerst weiteren Super-Admin anlegen." 37.18.6 Konto gesperrt nach Fehlversuchen: „Account gesperrt nach 10 Fehlversuchen. Bitte anderen Super-Admin um Reaktivierung bitten." 37.18.7 Lösch-Anstoß im Auftrag: „Du startest die Kündigung für Mandant ‚X‘ im Auftrag. Bestätigungs-Email geht an alle Mandanten-Administratoren mit Cancel-Link." 37.18.8 Legacy-Provider-Konflikt: „Legacy-Provider-Stand und HiveGrid-Stand weichen ab. Bitte manuell prüfen: [Legacy-Provider-Wert] vs. [HiveGrid-Wert]." 37.18.9 Warteschlangen-Pause: „Warteschlange ‚X‘ pausiert. Neue Aufgaben werden eingereiht aber nicht verarbeitet. Vergiss nicht zu reaktivieren!" 37.18.10 Massen-Email an Mandanten-Administratoren: „Diese Email geht an X Mandanten-Administratoren. Bitte nochmal Betreff und Inhalt prüfen. [Senden]"

Block 2: Stammdaten

Diese vier Module verwalten die Stammdaten, mit denen Geerkens täglich arbeitet: Kontakte, Firmen, eingehende Anfragen (Leads), Dateien, und die globale Suche, die alles auffindbar macht.

Modul 1: CRM-Kern (Kontakte und Firmen)

Was es tut: Zentrale Verwaltung aller Personen und Firmen, mit denen Geerkens zu tun hat, Kunden, Interessenten, Lieferanten, Partner. Jeder Kontakt und jede Firma hat eine eigene Detail-Seite mit Stammdaten, Notizen, Verknüpfungen zu Angeboten und Projekten und einem chronologischen Verlauf aller Aktivitäten. Löst ab: HubSpot CRM (Kontakte- und Firmen-Bereich). Warum es wichtig ist: Der CRM-Kern ist das Fundament, fast alle anderen Module (Angebote, Projekte, Aufträge, Termine, Dateien) verlinken auf Kontakte oder Firmen. Wenn das schief liegt, kippt der Rest.

1.1 Was zu einem Kontakt gespeichert wird

1.1.1 Pro Person wird gespeichert: Anrede, Titel, Vor- und Nachname (Pflicht), eine oder mehrere Email-Adressen mit Typ (privat/geschäftlich/Rechnung), eine oder mehrere Telefonnummern mit Typ, Adresse (Straße, PLZ, Ort, Land), Geburtstag (optional), Notizen als Freitext, bevorzugte Sprache für Mails (Deutsch oder Englisch), Hauptverantwortlicher Mitarbeiter, Quelle (woher kam der Kontakt, Formular, Mail, WhatsApp, Telefon, manuell, Import, Empfehlung), Kennzeichen "Privatkunde oder Geschäftskontakt". 1.1.2 Mehrere Email-Adressen und Telefonnummern pro Person sind möglich. Eine kann als Primär-Adresse markiert werden, die wird in Listen und beim Anschreiben automatisch verwendet. 1.1.3 Ein Kontakt kann mit mehreren Firmen verknüpft sein (z.B. Geschäftsführer von Firma A und Beirat von Firma B). Pro Verknüpfung wird die Rolle dort hinterlegt (Geschäftsführer, Hausmeister, Bauherr, ...) und welche Firma die Hauptzugehörigkeit ist. 1.1.4 Tags (frei vergebbare Schlagworte mit Farbe, z.B. "VIP", "Bestandskunde", "Wartungsvertrag") können beliebig hinzugefügt werden. 1.1.5 Branchen-Standard-Felder werden beim Anlegen eines neuen Workspace automatisch eingerichtet: für SHK-Betriebe sind das z.B. "Heizungsanlage Hersteller", "Heizungsanlage Modell", "Letzte Wartung" (Datum), "Wartungsvertrag" (Ja/Nein). Diese Liste ist anpassbar. 1.1.6 Kontakte können archiviert werden (verschwinden aus Listen, bleiben aber gespeichert) und später wieder aktiviert werden. Endgültiges Löschen ist nur durch Admins möglich, mit Klartext-Warnung über alle bestehenden Verknüpfungen.

1.2 Was zu einer Firma gespeichert wird

1.2.1 Pro Firma wird gespeichert: Firmenname (Pflicht), Rechtsform (GmbH, AG, Einzelunternehmer, GbR, UG, ...), USt-Identifikationsnummer und Steuernummer, Branche, Webseite, Standort-Adresse, Notizen, Hauptverantwortlicher Mitarbeiter. 1.2.2 An jeder Firma hängen die verknüpften Kontakte mit ihrer Rolle, ein primärer Ansprechpartner kann markiert werden. 1.2.3 Firmen haben dieselben Möglichkeiten wie Kontakte: Tags, eigene Branchen-Standard-Felder (z.B. "Anzahl Anlagen", "Vertragsklasse Standard/Premium/Custom"), archivierbar.

1.3 Eigene Felder pro Workspace

1.3.1 Workspace-Admins können eigene Felder anlegen und unterschiedlich für Kontakte, Firmen und Leads konfigurieren. Verfügbare Feld-Typen: Text, Zahl, Datum, Auswahl-Liste mit fester Optionen-Liste, Mehrfach-Auswahl, Ja/Nein-Schalter, URL, Email-Adresse. 1.3.2 Pro eigenem Feld ist einstellbar: Beschriftung, Hilfetext (erscheint als Tooltip), Pflichtfeld ja/nein, Reihenfolge in der Anzeige. 1.3.3 Eigene Felder können archiviert werden, die bisher eingegebenen Werte bleiben erhalten, das Feld wird nur ausgeblendet. Sie können auch endgültig gelöscht werden, mit Klartext-Warnung über die Anzahl betroffener Einträge. 1.3.4 Eigene Felder können in den Listen-Ansichten als Spalte sichtbar gemacht und als Filter verwendet werden. 1.3.5 In Phase 2: eigene Felder als Auslöser oder Bedingung in der Automation-Engine, erweiterte Validierung (z.B. Zahl muss zwischen X und Y liegen), feldspezifische Berechtigungen (z.B. "nur HR sieht 'Personalnummer'").

1.4 Listen-Ansichten

1.4.1 Es gibt eine Kontakt-Liste, eine Firmen-Liste und eine Lead-Liste (Lead-Liste ist im Modul 2 detailliert). 1.4.2 In der Kontakt-Liste sind pro Eintrag sichtbar: Name, Hauptfirma, Primär-Email, Primär-Telefon, Tags, Verantwortlicher, letzte Aktivität. 1.4.3 Welche Spalten sichtbar sind, kann jeder Mitarbeiter für sich anpassen und speichern. 1.4.4 Listen können sortiert werden (Standard: nach letzter Aktivität, neueste oben). 1.4.5 Suche in der Liste funktioniert über Name, Email, Telefon, Notizen und eigene Felder gleichzeitig. 1.4.6 Filter sind kombinierbar: Verantwortlicher (mehrere wählbar), Tags (mehrere mit "und" oder "oder"), Firma, Erstellt-Zeitraum, "hat verknüpftes Angebot/Projekt", eigene Felder. Schalter "Archivierte anzeigen" ist standardmäßig aus. 1.4.7 Mehrfach-Auswahl per Häkchen ermöglicht Sammel-Aktionen: Tag hinzufügen oder entfernen, Verantwortlichen ändern, archivieren, gefilterte Auswahl als CSV exportieren. 1.4.8 Bei großen Listen (10.000+ Einträge) wird seitenweise nachgeladen ("Mehr laden"-Button), damit nichts hängt.

1.5 Detail-Ansicht eines Kontakts

1.5.1 Sichtbar sind alle Stammdaten, alle Email- und Telefonnummern, alle verknüpften Firmen mit Rolle, Tags, Verantwortlicher, alle verknüpften Angebote und Projekte, alle hinterlegten Dateien, alle eigenen Felder, Notizen und der Aktivitäten-Verlauf. 1.5.2 Jedes Stammdaten-Feld kann direkt in der Ansicht bearbeitet werden (Klick → ändern → speichern oder abbrechen), ohne in einen separaten Bearbeiten-Modus wechseln zu müssen. 1.5.3 Direkt aus der Kontakt-Ansicht möglich: Anrufen (per Click-to-Call wenn Telefonie verbunden ist, sonst öffnet Telefon-App des Geräts), Mail schreiben (Vorlagen-Auswahl, Empfänger vorausgefüllt), Termin buchen, Angebot anlegen (Kontakt vorausgewählt), Aufgabe anlegen, Tags ändern, Verantwortlichen ändern, Firma verknüpfen oder lösen. 1.5.4 Notizen sind im Markdown-Format (einfache Formatierung wie Fett, Listen, Links). 1.5.5 Wenn ein Kontakt keine Email und kein Telefon hat: Klartext-Hinweis "Keine Kontaktdaten hinterlegt, Anrufen/Mailen erst nach Eingabe möglich". 1.5.6 Wenn ein Kontakt archiviert ist: Banner "Kontakt ist archiviert, wieder aktivieren um zu bearbeiten". 1.5.7 Endgültiges Löschen mit offenen Verknüpfungen erfordert mehrstufige Bestätigung mit Auflistung, wie viele Angebote, Projekte, Dateien und Aktivitäten betroffen sind. 1.5.8 DSGVO-Daten-Export auf Knopfdruck: alle gespeicherten Daten zu diesem Kontakt als ZIP-Download (Admin-Berechtigung nötig).

1.6 Detail-Ansicht einer Firma

1.6.1 Funktioniert genauso wie die Kontakt-Ansicht, mit zusätzlicher Verwaltung der verknüpften Kontakte (Rolle ändern, primären Ansprechpartner setzen). 1.6.2 Der Aktivitäten-Verlauf einer Firma zeigt alle Aktivitäten der verknüpften Kontakte plus firmen-eigene Aktivitäten.

1.7 Aktivitäten-Verlauf

1.7.1 An jedem Kontakt, jeder Firma, jedem Lead, jedem Angebot, jedem Projekt hängt ein chronologischer Verlauf, was passiert ist. 1.7.2 Erfasst werden automatisch: ein- und ausgehende Anrufe, gesendete und empfangene Mails (Phase 2: WhatsApp), Notizen, Tag-Änderungen, Verantwortlichen-Wechsel, Stage-Wechsel bei Angeboten/Projekten, Datei-Uploads, Formular-Eingänge, Aufgaben (angelegt/erledigt), Termine, Lead-Übernahmen, Angebot gewonnen/verloren, ausgelöste Automationen, KI-Aktionen. 1.7.3 Pro Eintrag ist sichtbar: Datum/Uhrzeit (relativ wenn jünger als 7 Tage, sonst absolut), wer es war (Mitarbeiter, System, Automation oder KI), Klartext-Beschreibung, Klick öffnet Detail-Anzeige mit allen Daten. 1.7.4 Filter im Verlauf: nach Aktivitäts-Typ, nach Mitarbeiter, nach Zeitraum. Suche im Klartext der Einträge. 1.7.5 Gruppierung nach Tagen: heute / gestern / diese Woche / älter. 1.7.6 Aktivitäten können nicht gelöscht und nicht bearbeitet werden, sie sind ein lückenloser Nachweis. Notizen sind die einzige Aktivität, die direkt erstellt werden kann. 1.7.7 Wer einen Kontakt nicht sehen darf, sieht auch dessen Aktivitäten nicht. Audit-Einträge (sicherheitsrelevant) sind nur mit Audit-Berechtigung sichtbar.

1.8 Suche und Duplikat-Erkennung

1.8.1 Innerhalb der Listen-Ansicht funktioniert Volltext-Suche über Name, Email, Telefon, Notizen, eigene Felder. 1.8.2 Bereits beim Tippen in einem Anlege-Formular wird gegen vorhandene Kontakte abgeglichen, bei exaktem Email- oder Telefon-Treffer kommt sofort ein Klartext-Hinweis "Es gibt bereits einen Kontakt mit dieser Email: [Name]" mit den Optionen "Diesen öffnen", "Trotzdem neu anlegen" oder "Daten zusammenführen". 1.8.3 Bei weichen Treffern (gleicher Vor-/Nachname plus gleiche Firma oder gleiche Postleitzahl) erscheint ein dezenter Hinweis "Möglicher Duplikat: [Name]", den der Mitarbeiter ignorieren kann. 1.8.4 Es gibt ein Admin-Werkzeug "Duplikate finden", das alle erkannten Duplikat-Paare auflistet. Pro Paar wird der Treffergrund angezeigt (gleiche Email / gleiche Telefonnummer / gleicher Name + Firma / gleicher Name + PLZ) sowie beide Datensätze nebeneinander mit Anzahl Aktivitäten und Verknüpfungen. 1.8.5 Beim Zusammenführen entscheidet der Admin pro Feld, welcher Wert übernommen wird. Verknüpfungen (Angebote, Projekte, Dateien, Aktivitäten) werden vollständig auf den Gewinner umgehängt. Tags werden vereinigt. Der Verlierer wird archiviert oder hart gelöscht (Workspace-Einstellung). Im Aktivitäten-Verlauf des Gewinners erscheint ein Merge-Eintrag mit Vorher-Nachher. 1.8.6 In Phase 2: KI-gestützte Smart-Duplikat-Erkennung, automatische Merge-Regeln (z.B. "bei exaktem Email-Match automatisch zusammenführen"), zeitgesteuerter Duplikat-Scan.

1.9 Tags (Schlagworte)

1.9.1 Tags haben einen Namen, eine Farbe (8 vordefinierte Farben für ein konsistentes Bild) und sind anwendbar auf bestimmte Entitäts-Typen (z.B. nur Kontakte, oder Kontakte und Firmen). 1.9.2 Mitarbeiter können Tags ad-hoc anlegen: einfach im Tag-Eingabefeld einen neuen Namen tippen → Vorschlag "+ Tag 'Bestandskunde' anlegen" → Klick → ist sofort gesetzt. 1.9.3 Es gibt eine Tag-Verwaltung (Admin), in der Tags umbenannt werden können (alle Verwendungen aktualisieren sich mit), die Farbe geändert werden kann, zwei Tags zusammengeführt werden können, oder ein Tag gelöscht werden kann (mit Warnung über die Anzahl betroffener Einträge). 1.9.4 Tags ohne Verwendung können automatisch nach 90 Tagen archiviert werden (Workspace-Einstellung).

1.10 Wer darf was sehen

1.10.1 Wer nur "eigene lesen" hat und versucht, einen fremden Kontakt direkt aufzurufen, sieht eine "Nicht gefunden"-Seite (404), nicht "Zugriff verweigert" (403), damit nicht ableitbar ist, ob der Kontakt überhaupt existiert. 1.10.2 Bearbeiten-Funktionen werden bei fehlender Berechtigung gar nicht erst angezeigt, nicht ausgegraut. 1.10.3 Sammel-Aktionen ohne Berechtigung sind ausgegraut mit Tooltip "Hierfür benötigst du erweiterte Berechtigungen". 1.10.4 Wenn ein Mitarbeiter gerade in einer Liste arbeitet und ein Kontakt wird ihm entzogen (Verantwortlicher gewechselt), verschwindet der Eintrag live aus seiner Liste.

1.11 Verknüpfungen mit anderen Modulen

1.11.1 Kontakt → Angebot (Modul 3): jedes Angebot gehört zu einem Kontakt und/oder einer Firma. 1.11.2 Kontakt → Projekt (Modul 4): nach gewonnenem Angebot wird ein Projekt angelegt, das auf den Kontakt verweist. 1.11.3 Kontakt → Datei (Modul 23): Dateien können einem oder mehreren Kontakten zugeordnet werden. 1.11.4 Kontakt → Termin (Modul 6/25), Aufgabe (Modul 26), Mail-Konversation (Modul 9), Anruf (Modul 12), Formular-Eingang (Modul 5), Lead (Modul 2, nach Übernahme). 1.11.5 Kontakt ist suchbar in der globalen Suche (Modul 24).

1.12 Phase 2 / bewusst NICHT in Phase 1

1.12.1 KI-gestütztes Smart-Match bei der Duplikat-Erkennung, Phase 1 nutzt feste Regeln. 1.12.2 Automatische Merge-Regeln und zeitgesteuerter Duplikat-Scan. 1.12.3 Eigene Felder als Trigger oder Bedingung in der Automation-Engine. 1.12.4 Erweiterte Validierung für eigene Felder (Regex, Zahlen-Bereich, abhängige Felder). 1.12.5 Berechtigungen pro eigenes Feld (z.B. "nur HR sieht 'Personalnummer'").

1.13 Klartext-Fehlertexte (Beispiele)

1.13.1 "Das Feld 'Heizungsanlage Hersteller' ist Pflicht." 1.13.2 "Es gibt bereits einen Kontakt mit dieser Email: Max Mustermann. [Diesen öffnen] [Trotzdem neu anlegen] [Daten zusammenführen]" 1.13.3 "15 Kontakte haben einen Wert in diesem Feld. Beim Löschen gehen Werte verloren. Stattdessen archivieren? [Archivieren] [Trotzdem löschen]" 1.13.4 "Dieser Tag ist 67 Mal verwendet. Beim Löschen werden alle Verknüpfungen entfernt, die Kontakte selbst bleiben."

Modul 2: Lead-Inbox (Eingehende Anfragen)

Was es tut: Sammelt alle unqualifizierten Eingänge an einer Stelle, Formular-Eingänge von der Webseite, Mails an die Info-Adresse, Anrufe von unbekannten Nummern, manuelle Einträge, und lässt das Vertriebs-Team triagieren: ernsthafte Anfrage oder Spam? Übernehmen oder verwerfen? Wer kümmert sich? Löst ab: HubSpot Lead-Bereich. Warum es wichtig ist: Geerkens kriegt ständig Anfragen über verschiedene Kanäle. Ohne zentrale Eingangs-Schublade gehen Anfragen unter oder werden doppelt bearbeitet.

2.1 Was ein Lead ist und wie er entsteht

2.1.1 Ein Lead ist eine "potenzielle Person", Daten sind noch nicht geprüft, vielleicht nicht mal vollständig. Erst beim Übernehmen ("Promotion") wird daraus ein vollwertiger Kontakt im CRM. 2.1.2 Ein Lead enthält: Vor- und Nachname (alle optional, Formulare sind manchmal dünn), Email, Telefon, Nachricht (Freitext), Quelle (woher kam er), Status, Verantwortlicher, Eingangs-Datum. 2.1.3 Quellen: Formular-Eingang (von einem Web-Formular), Mail (an die verbundene Mailbox, wenn Absender kein bekannter Kontakt ist), WhatsApp (Phase 2), Telefon (Anruf von unbekannter Nummer), manueller Eintrag (Mitarbeiter trägt selbst ein), Import (Phase 2), Empfehlung, sonstige. 2.1.4 Workspace-Admins können eigene Quellen anlegen (z.B. "Messe SHK 2027") mit Standard-Verantwortlichem und Standard-Tags. Manuell eingetragene Leads aus dieser Quelle landen vorsortiert.

2.2 Wie Leads automatisch entstehen

2.2.1 Formular-Eingang: Wenn jemand ein HiveGrid-Formular auf der Webseite abschickt (siehe Modul 5), wird automatisch ein Lead mit Quelle "Formular" angelegt. Bei Email- oder Telefon-Treffer auf einen vorhandenen Kontakt wird ein Hinweis im Lead-Detail angezeigt, das Zusammenführen ist immer Mensch-Entscheidung in Phase 1. 2.2.2 Eingehende Mail: Kommt eine Mail an die verbundene Mailbox von einem Absender, der kein bekannter Kontakt ist, wird ein Lead mit Quelle "Mail" angelegt und die Mail bleibt zugleich in der Inbox. Wenn der Absender bekannt ist, wird die Mail dem bestehenden Kontakt zugeordnet, kein Lead. 2.2.3 Anruf: Wenn ein Anruf von einer unbekannten Nummer eingeht, wird ein Lead mit Quelle "Telefon", der Nummer und einer Notiz "Anruf eingegangen am [Datum]" angelegt. Der Verantwortliche wird auf den Mitarbeiter gesetzt, der den Anruf entgegengenommen hat. Eine eventuelle Aufzeichnung wird verlinkt. 2.2.4 Manueller Eintrag: Mitarbeiter legen selbst einen Lead an (z.B. nach einem Messe-Gespräch). Beim Tippen wird live gegen vorhandene Kontakte geprüft. 2.2.5 Externe Quellen über Apps-Engine: Leads aus externen Marketing-Tools (z. B. Meta-Lead-Forms, Google-Lead-Ads, Funnel-Plattformen wie Funnelcockpit / Perspective Funnels) kommen über Adapter aus Modul 33a und werden mit Quelle „[Anbieter-Name]" angelegt. Konkrete Adapter-Implementierungen sind anhand des Bedarfs Geerkens priorisierbar.

2.3 Lead-Inbox (Listen-Ansicht)

2.3.1 Pro Lead sichtbar: Identität (Name falls vorhanden, sonst Email oder Telefon, sonst Quelle + Datum), Quelle, Status, Verantwortlicher, Eingangs-Datum, Vorschau der Nachricht (max. 80 Zeichen), letzte Aktivität. 2.3.2 Marker neben Einträgen: "Mögliches Duplikat" (wenn Email/Telefon mit existierendem Kontakt matcht), "Spam-Verdacht" (Anomalie-Erkennung hat angeschlagen), "Automatisch übernommen" (durch eine Automation). 2.3.3 Filter: Status (Standardmäßig sind "Neu" und "Qualifiziert" sichtbar), Quelle, Verantwortlicher (mit Sonderwert "Nicht zugewiesen"), Eingangs-Zeitraum, Tags, eigene Felder, Schalter "Spam ausblenden" (Standard ein), Schalter "Übernommene einblenden" (Standard aus). 2.3.4 Pro Eintrag direkt aus der Liste möglich, ohne in die Detail-Seite zu wechseln: Verantwortlichen zuweisen, Status setzen, zu Kontakt übernehmen (öffnet Modal), Spam markieren. 2.3.5 Sammel-Aktionen: Verantwortlichen zuweisen (auch per Round-Robin in einer Gruppe), Status setzen (mit Begründungs-Feld bei "verloren"), Tags ändern, Spam markieren mit Klartext-Bestätigung "124 Leads als Spam markieren? Sie werden in 30 Tagen automatisch gelöscht.", endgültig löschen, gefilterte Auswahl als CSV exportieren (Admin-Berechtigung). 2.3.6 Sortierung: Standard ist Eingangs-Datum, neueste oben. Andere Spalten sortierbar. 2.3.7 Neue Leads erscheinen automatisch in der Liste (Live-Aktualisierung), ohne dass die Seite neu geladen werden muss. 2.3.8 Mitarbeiter können bis zu 5 Filter-Kombinationen als "Gespeicherte Ansicht" speichern.

2.4 Lead-Detail-Ansicht

2.4.1 Sichtbar sind alle Lead-Daten plus die Quellen-Detail-Daten (z.B. welches Formular genau, mit welcher Submitter-IP, oder Mail-Header, oder Anruf-Aufzeichnungs-Link). 2.4.2 Treffer-Hinweise: "Es gibt einen Kontakt mit dieser Email: [Name], [Diesen Kontakt öffnen]" oder "Soft-Match: [Name + Adresse]". 2.4.3 Bei wiederholten Anfragen derselben Email innerhalb 30 Tagen wird der bisherige Verlauf angezeigt. 2.4.4 Direkt aus der Lead-Ansicht möglich: Annehmen (Status "Neu" wird "Qualifiziert"), zu Kontakt übernehmen (öffnet Übernahme-Modal), Spam markieren, Verloren markieren, Verantwortlichen ändern, Antwort senden (Mail, oder WhatsApp Phase 2), anrufen, Notiz hinzufügen, Aufgabe anlegen, Termin-Vorschlag senden. 2.4.5 Lead-Stammdaten können direkt geändert werden (Klick → ändern → speichern). 2.4.6 Endgültiges Löschen erfordert Klartext-Bestätigung.

2.5 Übernahme zu Kontakt

2.5.1 Mitarbeiter klickt "Als Kontakt übernehmen" → Modal öffnet sich mit Lead-Daten vorausgefüllt, alle Felder editierbar. 2.5.2 Optional: existierende Firma suchen oder eine neue anlegen, Rolle wählen. 2.5.3 Optional: gleichzeitig ein Angebot anlegen (Pipeline + Stufe + geschätztes Volumen, standardmäßig vorgeschlagen). 2.5.4 Automatischer Email-Abgleich: Wenn schon ein Kontakt mit dieser Email existiert, kann der Mitarbeiter wählen: (a) den bestehenden Kontakt aktualisieren (Standard, leere Felder werden ergänzt, ein Aktivitäts-Eintrag wird erzeugt), (b) trotzdem einen neuen Kontakt anlegen, (c) manuell einem anderen bestehenden Kontakt zuordnen (z.B. private vs. geschäftliche Email derselben Person), (d) als Spam markieren. 2.5.5 Bestätigen → in einem Schritt werden Kontakt, ggf. Firma und Verknüpfung, ggf. Angebot angelegt. Der Lead bekommt Status "Übernommen" und einen Verweis auf den entstandenen Kontakt. 2.5.6 Wenn Pflichtdaten für die Übernahme fehlen: "Um diesen Lead zu promovieren, brauchen wir mindestens Vor- und Nachname. [Daten ergänzen]".

2.6 Status-Verlauf eines Leads

2.6.1 Mögliche Status: "Neu" (unbearbeitet, Standard), "Qualifiziert" (manuell ernst eingestuft), "Übernommen" (wurde Kontakt, Status ist endgültig), "Verloren" (nicht weiterverfolgt, mit optionaler Begründung), "Spam" (markiert für automatische DSGVO-Löschung). 2.6.2 Übergänge: Neu → Qualifiziert (manuell oder durch Automation), Neu → Übernommen (durch Übernahme-Modal), Neu → Verloren oder Spam, Verloren ↔ Qualifiziert (z.B. Re-Engagement), Spam → Qualifiziert (False-Positive zurücknehmen). 2.6.3 Status "Übernommen" ist endgültig, wird nur durch Hard-Delete des entstandenen Kontakts mit zurückgenommen.

2.7 Automatische Löschung (DSGVO)

2.7.1 Leads im Status "Spam" werden nach 30 Tagen automatisch endgültig gelöscht (täglicher Job). 2.7.2 Leads im Status "Verloren" werden nach 90 Tagen endgültig gelöscht (Workspace-Admin kann das anpassen, "0 Tage" bedeutet "nie"). 2.7.3 Vor der automatischen Löschung wird im Lead-Detail eingeblendet: "Wird automatisch gelöscht am [Datum], [Status ändern um zu erhalten]". 2.7.4 Nach der Löschung bleibt ein anonymisierter Eintrag im Aktivitäts-Verlauf (kein Personenbezug) plus ein Audit-Eintrag.

2.8 Spam-Schutz und Anti-Flutung

2.8.1 Workspace-Admins können pro Quelle ein Stundenlimit setzen (Standard 100 Eingänge pro Stunde pro Quelle). Wird das überschritten, werden weitere Eingänge verworfen und ein Klartext-Hinweis geht an den Admin. 2.8.2 Pro IP-Adresse ist ein Stundenlimit für Formular-Eingänge konfigurierbar (Standard 20). 2.8.3 Anomalie-Erkennung: erkennt das System eine 10-fache Spitze gegenüber dem Üblichen, wird die Quelle automatisch pausiert und der Admin benachrichtigt: "Quelle 'Kontaktformular' wurde automatisch pausiert: 247 Submissions in 5 Minuten (10x üblich). Eingehende Leads werden verworfen. [Wieder aktivieren] [Anti-Spam-Einstellungen]". 2.8.4 Optionale Spam-Heuristiken (jede einzeln einschaltbar): IP auf Blocklist, Email-Domain ist Wegwerf-Mail-Anbieter, Honeypot-Feld im Formular gefüllt (Bot-Signal), Formular zu schnell abgeschickt (unter 3 Sekunden nach Laden, Bot-Signal). 2.8.5 Treffer-Verhalten ist wählbar: entweder "Quarantäne" (Status bleibt "Neu" mit Marker, Mensch entscheidet) oder "Direkt-Spam" (Status sofort "Spam" und im Default-Filter ausgeblendet).

2.9 Lead-Statistiken

2.9.1 Eigene Statistik-Seite mit Kennzahlen: eingegangene Leads im gewählten Zeitraum, Übernahme-Quote (Lead → Kontakt), Übernahme-Quote (Lead → gewonnenes Angebot), durchschnittliche Reaktionszeit (Eingang bis erste Antwort oder Status-Wechsel), Spam-Quote, offene Leads (nicht zugewiesen oder älter als 24 Stunden in "Neu"). 2.9.2 Aufschlüsselungen: nach Quelle (Volumen + Übernahme-Quote pro Quelle), nach Verantwortlichem, nach Tag, nach Wochentag/Tageszeit, aktuelle Status-Verteilung. 2.9.3 Trend-Anzeige: Lead-Volumen über Zeit, Übernahme-Quote über Zeit, Vergleich zur Vorperiode (Delta in Prozent). 2.9.4 Klick auf eine Quelle oder einen Mitarbeiter springt in die gefilterte Lead-Liste. 2.9.5 Aufschlüsselung "Nach Verantwortlichem" ist nur sichtbar für Mitarbeiter mit Lese-Berechtigung "Alle". Wer nur "Eigene" sehen darf, sieht nur eigene Zahlen. 2.9.6 Export der aktuellen Statistik-Sicht als CSV (Admin-Berechtigung).

2.10 Wer darf was sehen

2.10.1 Bei Sammel-Auswahl mit gemischten Rechten: "Du hast 50 Leads ausgewählt. 12 davon sind nicht dir zugewiesen, diese werden übersprungen. [Trotzdem fortfahren] [Auswahl anpassen]". 2.10.2 Lead übernehmen erfordert sowohl Lead-Bearbeiten- als auch CRM-Bearbeiten-Recht (weil dabei ein Kontakt entsteht).

2.11 Lead-Routing pro Quelle (mandanten-konfigurierbar) [N4, 09.05.2026]

Erweiterung gem. Anmerkung Noah, 09.05.2026: Leads kommen aus immer mehr Quellen, perspektivisch auch aus eigenen Marketing-Funnels (siehe 2.12.X für Phase 2). Pro Quelle muss konfigurierbar sein, was nach Eingang automatisch passiert: in welche Vertriebs-Pipeline der Lead landet, wer als Verantwortlicher gesetzt wird, ob automatisch ein Verkaufsfall (Deal) angelegt wird. Manuelles Sortieren skaliert nicht.

2.11.1 Pro Lead-Quelle (Formular, Mail-Postfach, Anruf-Nummer, externer Adapter, manuell) konfiguriert der Mandanten-Administrator ein Routing-Regelwerk. 2.11.2 Konfigurierbare Routing-Aktionen pro Quelle: - Status-Default (Neu / Qualifiziert). - Verantwortlicher-Default: konkrete Person, Round-Robin innerhalb einer Gruppe (z. B. Vertriebs-Team), oder Lead-Pool (Phase 2). - Tags-Default (eine oder mehrere). - Auto-Anlage Verkaufsfall: bei Quellen mit klarem Vertriebs-Intent (z. B. Funnel „PV-Anlage konfigurieren") kann automatisch ein Verkaufsfall in einer konfigurierbaren Ziel-Pipeline und Start-Stufe angelegt werden, mit Lead-Daten vorausgefüllt. - Auto-Pipeline-Zuweisung: in welche Sales-Pipeline geht der entstehende Verkaufsfall? Mehrere Pipelines möglich (z. B. „Premium-Pipeline" für Volumen über 10.000 Euro, sonst „Standard-Pipeline"). - Bedingungen pro Regel (zum Beispiel „nur wenn Volumen-Feld > X" oder „nur wenn Anlagen-Typ = Wärmepumpe"). 2.11.3 Mehrere Regeln pro Quelle möglich, in Reihenfolge geprüft, erste Treffer-Regel zählt. Letzte Regel ist Default-Fallback. 2.11.4 Beispiele für Geerkens: - Quelle „Kontaktformular Webseite" → Status „Neu", Verantwortlicher Round-Robin Vertriebs-Team, Tag „Webseite", Auto-Verkaufsfall in „Anlagen-Verkauf" Pipeline. - Quelle „Anruf 0800-Nummer" → Status „Neu", Verantwortlicher der Mitarbeiter im Anruf, kein Auto-Verkaufsfall (Mitarbeiter qualifiziert manuell). - Quelle „Funnel PV-Konfigurator" → Status „Qualifiziert" (weil Konfiguration ausgefüllt), Verantwortlicher Vertriebsleiter, Auto-Verkaufsfall mit Volumen aus Konfigurator. 2.11.5 Routing-Konfiguration ist auditierbar (siehe Modul 21). Routing-Aktionen werden im Lead-Aktivitäts-Strom mit Klartext geloggt: „Automatisch der Pipeline ‚Anlagen-Verkauf' zugewiesen, Regel ‚Webseite-Kontaktformular'." 2.11.6 Klassische Lead-Inbox bleibt unverändert: Leads ohne automatische Verkaufsfall-Anlage landen wie bisher in der Lead-Inbox zur manuellen Qualifizierung. Auto-Routing ist eine Erweiterung, kein Ersatz.

2.12 Phase 2 / bewusst NICHT in Phase 1

2.12.1 CSV/JSON-Lead-Import (z.B. Migration aus HubSpot/Quiply). 2.12.2 Sammel-Übernahme mehrerer Leads in einem Rutsch. 2.12.3 KI-Lead-Bewertung (automatische Priorisierung und Punktzahl). 2.12.4 WhatsApp als Quelle (vollständig, in Phase 1 nicht). 2.12.5 Round-Robin-Auto-Verteilung mit Tenant-Admin-Regeln auf Gruppen-Ebene. 2.12.6 Lead-Pool-Gruppen (nicht zugewiesene Leads sichtbar für Gruppen-Mitglieder). 2.12.7 Erweiterte Statistiken: Funnel-Visualisierung, Marketing-Kosten-Verknüpfung, Cohort-Analyse. 2.12.8 KI-gestützter Spam-Filter, KI-Antwort-Vorschläge, KI-Routing. 2.12.9 Eigene Marketing-Funnels in HiveGrid bauen (Funnel-Builder mit Schritt-Logik, Konfiguratoren, Lead-Magneten, Tracking) [N4]. Integration mit der Automation-Engine (M17) und der Lead-Inbox (M02). Bedeutet ein eigenes Sub-Modul, daher Phase 2.

2.13 Klartext-Hinweise

2.13.1 Inbox leer: "Noch keine Leads, sobald über Formulare, Mails oder Anrufe Eingänge kommen, erscheinen sie hier. [Formular anlegen] [Mail-Inbox verbinden]". 2.13.2 Filter ohne Treffer: "Keine Leads passen zu deinen Filtern. [Filter zurücksetzen]". 2.13.3 Lead älter als 24 Stunden ohne Verantwortlichen: "Seit X Stunden unbearbeitet, [Mir zuweisen]". 2.13.4 Spam markiert: "Lead als Spam markiert. Wird am [Datum + 30 Tage] automatisch gelöscht. [Wiederherstellen]". 2.13.5 Quelle pausiert (Admin-Sicht): "Quelle 'Messe SHK 2027' ist pausiert, eingehende Leads aus dieser Quelle werden derzeit verworfen. [Reaktivieren]".

Modul 23: Dateien (Dokumentenablage)

Was es tut: Zentrale Ablage für alle Dokumente, Bilder, Verträge, Fotos von der Baustelle, Angebote als PDF, eine Datei kann gleichzeitig zu mehreren Stellen gehören (Kontakt, Firma, Angebot, Projekt, Auftrag). Mit Versionsverwaltung, Vorschau im Browser und mobiler Foto-Aufnahme direkt von der Baustelle. Löst ab: Datei-Anhänge in HubSpot und ad-hoc Dropbox-Nutzung bei Geerkens. Warum es wichtig ist: Handwerker leben von Fotos und Dokumenten, Anlagen-Fotos vor Montage, Mess-Berichte, Wartungs-Protokolle, unterschriebene Aufträge. Ohne zentrale, durchsuchbare Ablage liegt das alles in WhatsApp-Chats und Mail-Anhängen.

23.1 Wo Dateien gespeichert werden

23.1.1 Alle Dateien werden auf europäischen Servern gespeichert (Scaleway in Frankreich, DSGVO-konform). Kein US-Cloud-Anbieter, keine Datenübertragung in die USA. 23.1.2 Dateien sind verschlüsselt gespeichert (Server-seitig). 23.1.3 Pro Workspace sind die Dateien strikt voneinander getrennt, kein Workspace kann auf Dateien eines anderen zugreifen. 23.1.4 Download-Links sind nicht öffentlich, sie sind anmeldepflichtig und nur kurze Zeit gültig (5 Minuten). 23.1.5 Tägliche Multi-Zonen-Sicherung durch den Anbieter, plus tägliche Snapshots.

23.2 Was zu einer Datei gespeichert wird

23.2.1 Pro Datei: Anzeige-Name (übernimmt den Original-Dateinamen beim Hochladen, ist aber später umbenennbar), Dateityp, Größe, Erstellt-Datum + wer hochgeladen hat, aktuelle Versionsnummer, Tags, Notizen, Verantwortlicher, Quelle (manuell hochgeladen / über Kunden-Portal / aus Formular-Eingang / aus Mail-Anhang / durch Automation / über externe Schnittstelle), Verknüpfungen zu anderen Einträgen (Kontakte, Firmen, Leads, Angebote, Projekte, Aufträge, Aufgaben, Termine, Mitarbeiter, Formular-Eingänge). 23.2.2 Dateien werden über eine Prüfsumme (SHA-256) erkannt, beim Hochladen wird geprüft, ob dieselbe Datei schon existiert (siehe Duplikat-Erkennung). 23.2.3 Dateien können archiviert werden (verschwinden aus Listen, bleiben aber gespeichert) und endgültig gelöscht werden (Admin-Recht; löscht alle Versionen und Vorschauen mit).

23.3 Hochladen

23.3.1 Hochladen über Drag-and-Drop in den Browser, Datei-Auswahl-Dialog, oder direkt aus der Detail-Ansicht eines Kontakts/Angebots/Projekts (Datei wird automatisch verknüpft). 23.3.2 Mehrere Dateien gleichzeitig hochladbar (Warteschlange wird abgearbeitet). 23.3.3 Pro Datei wird der Fortschritt angezeigt: Name, Prozent + Datentransfer ("12 MB von 47 MB"), geschätzte Restzeit. Bei Fehlschlag steht eine Klartext-Begründung da plus eine Wiederholen-Option. 23.3.4 Maximale Dateigröße: 500 MB Standard, vom Workspace-Admin bis 2 GB anhebbar. Phase 2: Speicher-Limits pro Subscription-Plan. 23.3.5 Bestimmte Dateitypen sind aus Sicherheitsgründen blockiert (z.B. ausführbare Programme): "Dateityp '[Typ]' ist aus Sicherheitsgründen nicht erlaubt".

23.4 Mobile-Upload und Baustelle

23.4.1 In der Mobile-App: Foto direkt mit der Kamera aufnehmen → wird sofort hochgeladen. 23.4.2 Bei Funkloch oder unterbrochener Verbindung: Foto wird lokal auf dem Gerät zwischengespeichert. Sobald wieder online, wird automatisch hochgeladen. 23.4.3 Bei großen Dateien und schwacher Verbindung: Hochladen geht häppchenweise (in 5-MB-Stücken) und kann nach Verbindungsabbruch fortgesetzt werden, ohne von vorn zu beginnen. 23.4.4 Klartext bei Verbindungsabbruch: "Verbindung unterbrochen. Bereits hochgeladene Daten bleiben, Upload wird fortgesetzt sobald du wieder online bist".

23.5 Versionsverwaltung

23.5.1 Wenn jemand eine neue Version derselben Datei hochlädt (z.B. überarbeitetes Angebot), bleibt die alte Version vorhanden. Versionsnummern sind fortlaufend (V1, V2, V3, ...). 23.5.2 Beim Hochladen einer neuen Version kann optional ein Änderungs-Hinweis hinterlegt werden ("Preise korrigiert", "Unterschrift hinzugefügt", ...). Ohne Hinweis wird ein Standard-Text "Version hochgeladen am [Datum]" gesetzt. 23.5.3 Bei Upload eines gleichnamigen Dokuments im Kontext eines Projekts/Angebots: "Es gibt bereits eine Datei 'angebot.pdf' in diesem Projekt. Möchtest du eine neue Version anlegen oder eine separate Datei?". 23.5.4 In der Detail-Ansicht ist der vollständige Versionsverlauf einsehbar: pro Version Datum, hochladende Person, Größe, Änderungs-Hinweis, jede Version einzeln herunterladbar und vorschaubar. 23.5.5 Zurück zu einer alten Version ("Rollback"): legt eine neue Version mit dem Inhalt der alten an. Es wird nichts überschrieben, der Verlauf bleibt lückenlos. 23.5.6 Endgültiges Löschen einer Datei entfernt alle Versionen, alle Vorschauen, alle Verknüpfungen.

23.6 Vorschau im Browser

23.6.1 Direkt im Browser angezeigt werden: PDFs, Bilder (JPEG, PNG, GIF, WebP, HEIC, HEIC wird automatisch in JPEG konvertiert für Browser-Kompatibilität), Office-Dokumente (Word, Excel, PowerPoint und LibreOffice-Pendants, werden in PDF umgewandelt), Videos (Browser-Player), Audio (Player), reiner Text und Markdown. 23.6.2 Für nicht unterstützte Dateitypen: nur Download-Funktion, mit Klartext-Hinweis "Für diesen Dateityp ist keine Vorschau verfügbar. [Herunterladen]". 23.6.3 Vorschau-Erstellung läuft im Hintergrund. Status sichtbar: "Vorschau wird erstellt, kann einen Moment dauern" / "Vorschau bereit" / "Vorschau fehlgeschlagen, Datei kann heruntergeladen und lokal geöffnet werden. [Erneut versuchen]". 23.6.4 Für jeden Versions-Stand wird eine eigene Vorschau erzeugt.

23.7 Listen-Ansicht (Datei-Browser)

23.7.1 Alle Dateien des Workspace in einer durchsuchbaren Liste, wahlweise als Tabelle oder als Kachel-Ansicht mit Vorschau-Bildchen. 23.7.2 Pro Eintrag sichtbar: Name, Typ, Größe, Erstellt-Datum + Ersteller, aktuelle Version, Tags, Verantwortlicher, verknüpfte Einträge (Anzahl + erste 1-2 als Klartext, Rest als "+N"), Quelle, Vorschau-Bildchen wenn verfügbar. 23.7.3 Filter: nach verknüpftem Eintrag (z.B. "alle Dateien zu Kunde Müller"), nach Typ-Gruppe (Bild / PDF / Office / Video / Audio / Sonstige), nach Verantwortlichem, nach Ersteller, nach Tags, nach Erstellt-Zeitraum, nach Quelle, nach Größe. 23.7.4 Datei-Browser ist auch eingebettet in den Detail-Seiten der anderen Module sichtbar, als "Dateien"-Sektion am Kontakt, an der Firma, am Angebot, am Projekt, am Lead, vorgefiltert auf den Eintrag. 23.7.5 Schnell-Vorschau beim Klick auf einen Eintrag (ohne in die Detail-Seite zu wechseln). 23.7.6 Sammel-Aktionen: Tag ändern, Verantwortlichen ändern, an Eintrag verknüpfen oder lösen, archivieren, gemeinsam als ZIP herunterladen, endgültig löschen.

23.8 Detail-Ansicht einer Datei

23.8.1 Sichtbar: Stammdaten, aktuelle Vorschau, Tags, Notizen, alle Verknüpfungen (gruppiert nach Typ, Kontakte, Firmen, Angebote, Projekte etc., mit optionaler Rolle pro Verknüpfung wie z.B. "Auftragsbestätigung", "Foto vor Montage", "Acceptance-Beleg"), Versionsverlauf, Aktivitäten-Verlauf (wer hat hochgeladen, wer hat verknüpft, wer hat umbenannt). 23.8.2 Direkt aus der Detail-Ansicht: aktuelle Version herunterladen, alte Version herunterladen, neue Version hochladen, umbenennen (Original-Datei bleibt unverändert, nur Anzeige-Name ändert sich), Notizen ändern, Tags ändern, Verantwortlichen ändern, Verknüpfung hinzufügen oder lösen, Vorschau erneut erzeugen (bei Fehlschlag), archivieren oder reaktivieren, endgültig löschen, DSGVO-Daten-Export, Permalink kopieren (anmeldepflichtige URL, kein öffentlicher Link in Phase 1).

23.9 Verknüpfungen mit anderen Modulen

23.9.1 Eine Datei kann gleichzeitig zu mehreren Einträgen gehören. Beispiel: Angebots-PDF gehört zum Kontakt, zum Angebot und nach Gewinn auch zum Projekt, das ist eine Datei, drei Verknüpfungen. 23.9.2 Verknüpfung optional mit Rollen-Beschreibung als Freitext ("Foto vor Montage", "Auftragsbestätigung", ...). 23.9.3 Verknüpfung hinzufügen erfordert sowohl Datei-Bearbeiten-Recht als auch Lese-Recht auf den Ziel-Eintrag. Klartext bei fehlendem Zugriff: "Du hast keinen Zugriff auf [Ziel-Name]. Bitte einen Kollegen mit Zugriff bitten, die Verknüpfung hinzuzufügen". 23.9.4 Datei-Uploads aus dem Kunden-Portal (Modul 15) werden automatisch dem zugehörigen Projekt/Angebot/Auftrag zugeordnet, mit Quelle "Kunden-Portal" und dem Namen des hochladenden Endkunden in der Anzeige. 23.9.5 Datei-Uploads aus Formular-Eingängen (Modul 5) werden automatisch der Formular-Einreichung zugeordnet. 23.9.6 HR-Dokumente am Mitarbeiter (z.B. Lohnabrechnungen) folgen Sonder-Berechtigungen aus dem HR-Hub (Modul 14): Standard ist "nur der betroffene Mitarbeiter selbst plus HR-Admin", auch andere Datei-Lese-Rechte greifen hier nicht. 23.9.7 KWP-Archiv-Spiegelung (KWP → HiveGrid, einseitig) [N5, 09.05.2026] - Pro Kunde gibt es in HiveGrid ein Kunden-Archiv mit allen Dokumenten, die KWP zum Kunden ablegt (auftrags-übergreifend, also Stammdaten-Schreiben, Kunden-Korrespondenz, Wartungs-Verträge etc.). - Pro Projekt gibt es ein Projekt-Archiv mit den auftrags-spezifischen Dokumenten aus KWP. - Beim Sync wird automatisch geprüft, in welche Archiv-Ebene das Dokument gehört (anhand der KWP-Verknüpfung Auftrag/Kunde) und in HiveGrid entsprechend abgelegt. - Sync-Richtung ist einseitig: KWP → HiveGrid. HiveGrid-eigene Dokumente werden nicht automatisch nach KWP gepusht (sonst KWP-Speicher-Überlauf), nur auf manuellen Knopfdruck einzelner Dokumente. - Detail-Anforderungen siehe 19.2.5.

23.10 Duplikat-Erkennung beim Hochladen

23.10.1 Wird eine Datei hochgeladen, die per Prüfsumme schon im Workspace existiert, kommt der Hinweis: "Diese Datei existiert bereits als '[Name]' in diesem Workspace. [Neue Version anlegen] [Verknüpfung hinzufügen] [Trotzdem neu speichern]".

23.11 Wer darf was sehen

23.11.1 Wer eine Datei nicht sehen darf, sieht sie auch nicht in Suchergebnissen. 23.11.2 HR-Dokumente am Mitarbeiter sind ausgenommen, auch "Alle lesen" sieht hier nichts ohne HR-Berechtigung.

23.12 Klartext-Hinweise

23.12.1 Verbindung beim Upload unterbrochen: "Verbindung unterbrochen. Bereits hochgeladene Daten bleiben, Upload wird fortgesetzt sobald du wieder online bist". 23.12.2 Datei zu groß: "Datei ist [Größe] groß. Maximale Dateigröße in diesem Workspace: [Maximum]. Frag deinen Workspace-Admin, wenn du größere Dateien hochladen musst". 23.12.3 Speicher-Limit erreicht (Phase 2): "Speicher-Limit dieses Workspace ist erreicht. Bitte alte Dateien archivieren oder Plan upgraden". 23.12.4 Hard-Delete-Warnung: "Diese Datei hat [n] Versionen und ist mit [m] Einträgen verknüpft. Beim Löschen gehen alle Versionen und Verknüpfungen verloren. Stattdessen archivieren? [Archivieren] [Endgültig löschen]". 23.12.5 Kunden-Portal-Upload erkannt: "Diese Datei wurde von [Endkunde] über das Kunden-Portal hochgeladen am [Datum]".

23.13 Phase 2 / bewusst NICHT in Phase 1

23.13.1 OCR (Texterkennung in PDFs und Bildern), damit der Inhalt durchsuchbar wird. 23.13.2 KI-gestützte automatische Tag-Vorschläge basierend auf Inhalt. 23.13.3 Speicher-Limits pro Subscription-Plan. 23.13.4 Automatisches Archivieren von Dateien nach X Monaten ohne Zugriff. 23.13.5 Öffentliche Teilen-Links (z.B. Angebot per Link an Kunden, separat vom Kunden-Portal). 23.13.6 Wasserzeichen für PDFs (z.B. mit Empfänger-Name). 23.13.7 Versions-Vergleich (Diff-Ansicht für PDFs/Office). 23.13.8 Ordner-Strukturen (bewusst NICHT in Phase 1, Tags + Verknüpfungen + Filter ersetzen Ordner; Ordner würden inkonsistente Ablage fördern). 23.13.9 Datei-Sperre beim parallelen Bearbeiten (für Office-Online-Integration). 23.13.10 Kundeneigene Verschlüsselungs-Schlüssel (Enterprise-Stufe). 23.13.11 Download-Tracking (wer hat wann was heruntergeladen), bewusst nicht in Phase 1 wegen Audit-Last.

Modul 24: Globale Suche

Was es tut: Eine Suche, die alles im Workspace findet, Kontakte, Firmen, Leads, Angebote, Projekte, Dateien, Aufgaben, Mitarbeiter, Formular-Eingänge, über eine Tastenkombination (Cmd+K bzw. Strg+K) von überall aufrufbar. Findet sowohl Stichwort-Treffer als auch sinnverwandte Treffer (KI-Suche). Löst ab: Verteilte Such-Funktionen in HubSpot und das ständige Wechseln zwischen Modulen, um etwas wiederzufinden. Warum es wichtig ist: Mitarbeiter wissen oft nicht mehr, ob das Gesuchte ein Kontakt, ein Angebot oder ein Projekt war, die globale Suche schließt diese Lücke und macht die Plattform spürbar schneller.

24.1 Wie die Suche aufgerufen wird

24.1.1 Tastenkombination Cmd+K (Mac) oder Strg+K (Windows/Linux), funktioniert von jeder Seite in der App. 24.1.2 Klick auf das Such-Symbol in der Kopfzeile der App. 24.1.3 Auf dem Handy: Such-Symbol in der Kopfzeile, öffnet eine Vollbild-Suche. 24.1.4 Direkter Link auf eine vorab gefilterte Suche möglich (z.B. "/search?q=Schmidt", kann gespeichert oder geteilt werden, Filter werden in der URL mitgenommen).

24.2 Was durchsucht wird (Phase 1)

24.2.1 Kontakte, Firmen, Leads (aus Modul 1 und 2). 24.2.2 Angebote (aus Modul 3, Sales-Pipeline). 24.2.3 Projekte und Aufträge (aus Modul 4). 24.2.4 Formular-Eingänge (aus Modul 5). 24.2.5 Mitarbeiter (aus Modul 14, mit eingeschränkter Sichtbarkeit, normaler Mitarbeiter sieht nur sich selbst und ggf. Kollegen mit entsprechender HR-Berechtigung). 24.2.6 Dateien (aus Modul 23, Name, Notizen, Tags; OCR-Inhalt der Dateien erst in Phase 2). 24.2.7 Aufgaben (aus Modul 26). 24.2.8 Phase 2: Wiki-Seiten (Modul 16), Mail-Inhalte (Modul 9 mit DSGVO-Schicht), Chat-Nachrichten (Modul 13 mit sehr restriktiven Berechtigungen).

24.3 Wie gesucht wird

24.3.1 Stichwort-Suche: findet exakte Treffer und Wortformen (deutsche Stammform-Erkennung, "Heizung" findet auch "Heizungen", "geheizt"). Umlaute werden normalisiert. 24.3.2 KI-Suche (semantisch): findet sinngemäße Treffer auch ohne genaue Wort-Übereinstimmung. Beispiel: Suche nach "Wartung Frühjahr" findet auch ein Projekt "Saisonale Heizungsinspektion März". 24.3.3 Beide Pfade laufen gemeinsam, Treffer werden zusammengeführt mit einem Mischverhältnis von 70% Stichwort und 30% KI (in Phase 2 vom Workspace-Admin anpassbar). 24.3.4 Zusätzliche Treffer-Bevorzugung: aktuelle Aktivität (Eintrag wurde kürzlich bearbeitet), exakter Treffer im Titel, eigene Einträge des suchenden Mitarbeiters. 24.3.5 Die KI-Suche läuft ausschließlich über europäische Anbieter (Mistral primär, Scaleway als Backup, AlephAlpha als drittes Backup). Keine Datenübertragung in die USA.

24.4 Treffer-Ansicht (Schnell-Suche im Modal)

24.4.1 Sichtbar pro Treffer: Titel (z.B. Kontakt-Name, Angebots-Titel), Untertitel (z.B. Firma beim Kontakt, Stage beim Angebot), Typ-Indikator (Kontakt / Firma / Angebot / Datei / ...), Kontext-Auszug mit hervorgehobener Treffer-Stelle, letzte Aktivität (relativ). 24.4.2 Treffer sind nach Typ gruppiert (zuerst Kontakte, dann Angebote, dann Dateien, ...). 24.4.3 Tastatur-Bedienung: Pfeiltasten zum Navigieren, Enter zum Öffnen, Cmd+Enter um in neuem Tab zu öffnen, Esc zum Schließen. 24.4.4 Filter-Chips am oberen Rand: "Nur Kontakte", "Nur Dateien", "Nur Angebote" etc., Mehrfach-Auswahl möglich. 24.4.5 Bei leerer Eingabe: zuletzt durchgeführte Suchen (siehe 24.7). 24.4.6 Bei keinem Treffer: "Keine Treffer für '[Suchbegriff]'. Versuch andere Begriffe oder erweitere den Zeitraum-Filter". 24.4.7 Lade-Anzeige während die Suche läuft. Stichwort-Treffer erscheinen sofort (unter 500 ms), KI-Treffer werden nachgeladen (1-3 Sek bei Erst-Suche), die Liste füllt sich live auf. 24.4.8 "Alle Treffer anzeigen" springt in die Vollbild-Such-Seite mit denselben Filtern.

24.5 Vollbild-Such-Seite

24.5.1 Eigene Seite mit Such-Eingabe, vollständiger Trefferliste, seitenweise nachladbar (50 pro Seite). 24.5.2 Erweiterte Filter-Sektion: Typ (Mehrfach-Auswahl), Erstellt-Zeitraum, Verantwortlicher, Tags, modul-spezifische Filter (z.B. Stage bei Angebot-Filter), Schalter "Archivierte einbeziehen". 24.5.3 Sortierung wählbar: Relevanz (Standard), letzte Aktivität, Erstellt-Datum. 24.5.4 Trefferanzahl im Klartext: "1.247 Treffer in 0,3 Sek".

24.6 Wer sieht welche Treffer

24.6.1 Die Suche zeigt nur Treffer, die der suchende Mitarbeiter aufgrund seiner Berechtigungen ohnehin sehen darf. Wer nur "eigene Kontakte" lesen darf, sieht in der Suche auch nur eigene Kontakte. 24.6.2 Die Filterung passiert auf dem Server, bevor Treffer im Browser ankommen, es ist nicht möglich, durch geschicktes Suchen Existenz versteckter Einträge abzuleiten. 24.6.3 Trefferanzahl bezieht sich immer auf die für den Mitarbeiter sichtbaren Treffer. 24.6.4 Bei stark reduzierter Anzeige durch Berechtigungen: dezenter Hinweis "Es gibt weitere Treffer, die du aufgrund deiner Berechtigungen nicht siehst" (ohne konkrete Anzahl, damit nicht ableitbar). 24.6.5 Suchanfragen werden im Audit-Log protokolliert (Inhalt der Anfrage, Trefferanzahl, Zeitstempel).

24.7 Zuletzt durchgeführte Suchen

24.7.1 Pro Mitarbeiter werden die letzten 50 Suchen gespeichert (Suchbegriff, gewählte Filter, Trefferanzahl). 24.7.2 Bei leerer Sucheingabe werden die letzten Suchen angezeigt, Klick wiederholt die Suche. 24.7.3 Einzelne Einträge können gelöscht werden, oder alle auf einmal über die Mitarbeiter-Einstellungen. 24.7.4 Auto-Bereinigung: ältere als 90 Tage werden automatisch entfernt. 24.7.5 Zuletzt durchgeführte Suchen sind privat, kein Workspace-Admin sieht sie. Beim DSGVO-Daten-Export des Mitarbeiters sind sie Teil des Exports.

24.8 Wie schnell die Suche ist

24.8.1 Erste Antwort (Stichwort-Treffer) unter 500 ms im Median. 24.8.2 KI-Treffer: 300 ms bei warmer Cache (häufige Anfrage), 1-3 Sek bei kalter Cache (Erst-Anfrage). 24.8.3 Zwischen Tippen und Such-Auslösung 300 ms Wartezeit (sonst würde bei jedem Buchstaben eine Anfrage rausgehen). 24.8.4 Neue oder geänderte Einträge erscheinen 5-10 Sekunden nach der Änderung in der Suche. Klartext-Hinweis falls direkt nach Anlegen gesucht und nicht gefunden: "Neue Einträge erscheinen ein paar Sekunden nach dem Anlegen in der Suche".

24.9 Was passiert wenn die KI-Suche ausfällt

24.9.1 Wenn der primäre KI-Anbieter nicht erreichbar ist, wird automatisch auf den nächsten ausgewichen. 24.9.2 Wenn alle KI-Anbieter ausfallen: Stichwort-Suche läuft trotzdem, Banner im Such-Modal: "Erweiterte semantische Suche ist gerade nicht verfügbar, Treffer kommen nur aus der Volltext-Suche".

24.10 Wer darf die Suche nutzen

24.10.1 Was tatsächlich gefunden wird, wird über die Modul-Berechtigungen (CRM, Angebote, Dateien etc.) gesteuert, die Suche selbst hat sehr leichte Berechtigungen.

24.11 Klartext-Hinweise

24.11.1 Keine Treffer: "Keine Treffer für '[Suchbegriff]'. Versuch andere Begriffe oder erweitere den Zeitraum-Filter". 24.11.2 Suchbegriff zu kurz: "Tippe mindestens 2 Zeichen für die Suche". 24.11.3 KI-Suche aus: "Erweiterte semantische Suche ist gerade nicht verfügbar, Treffer kommen nur aus der Volltext-Suche". 24.11.4 Server-Fehler: "Suche ist gerade nicht erreichbar. Bitte in einer Minute nochmal versuchen". 24.11.5 Re-Indexierung läuft (Admin-Aktion): "Such-Index wird neu aufgebaut. Suche kann temporär unvollständig sein. Status: [Fortschritt]%".

24.12 Phase 2 / bewusst NICHT in Phase 1

24.12.1 Gespeicherte Suchen: Mitarbeiter speichert Suchbegriff + Filter unter einem Namen, ruft sie aus Dropdown auf. 24.12.2 Erweiterte Such-Operatoren wie "kontakt:max@firma.de status:aktiv typ:angebot". 24.12.3 Such-Statistik für Workspace-Admins: häufige Suchen, Suchen ohne Treffer (Hinweis auf fehlende Inhalte), Klick-Quote pro Treffer. 24.12.4 Personalisierte Reihenfolge: Treffer-Bevorzugung basierend auf bisherigem Klick-Verhalten. 24.12.5 Mehrsprachige Suche (sobald die Plattform mehrere Sprachen unterstützt). 24.12.6 OCR-Inhalte aus PDFs und Bildern werden mitdurchsucht (sobald OCR aus Modul 23 aktiv ist). 24.12.7 Wiki-Seiten, Mail-Inhalte, Chat-Nachrichten als durchsuchbare Quellen. 24.12.8 Workspace-Admin kann Mischverhältnis Stichwort/KI selbst anpassen.

Block 3: Workflow-Kern (Vertrieb und Auftrag)

Hier passiert das Geerkens-Tagesgeschäft: Eine Anfrage wird zum Verkaufsfall, der Verkaufsfall wird gewonnen und automatisch zum Auftragsprojekt, das Auftragsprojekt wird über Plantafel und Abnahme zum abgeschlossenen Auftrag. Aufgaben begleiten alle Schritte.

Modul 3: Sales-Pipeline (Verkaufsfälle)

Was es tut: Bildet den kompletten Vertriebsprozess ab, von der ersten Anfrage über Besichtigung, Angebot und Verhandlung bis zur Gewonnen- oder Verloren-Entscheidung. Verkaufsfälle (intern „Deals" genannt) durchlaufen frei konfigurierbare Stufen in einer oder mehreren Pipelines. Löst ab: HubSpot Sales-Pipeline. Warum es wichtig ist: Geerkens kennt das Pipeline-Denken aus HubSpot und steuert daran das Vertriebs-Tagesgeschäft. Ohne sauberes Pipeline-Modul gibt es keinen sinnvollen Wechsel von HubSpot zu HiveGrid.

3.1 Was zu einem Verkaufsfall gespeichert wird

3.1.1 Eindeutige Verkaufsfall-Nummer, fortlaufend pro Mandant (Beispiel: „D-2026-0042"). Wird beim Anlegen automatisch vergeben. 3.1.2 Titel (Pflichtfeld, kurze Beschreibung des Vorhabens). 3.1.3 Längere Beschreibung als Freitext mit einfachen Formatierungen. 3.1.4 Pipeline und aktuelle Stufe. 3.1.5 Volumen (geschätzter Auftragswert in Euro). 3.1.6 Erwarteter Abschluss-Termin (geschätztes Datum). 3.1.7 Tatsächlicher Abschluss-Termin (wird gesetzt, sobald „Gewonnen" oder „Verloren"). 3.1.8 Verantwortlicher Vertriebler (Pflichtfeld). Jeder Verkaufsfall hat zwingend eine zuständige Person, das Feld darf nicht leer bleiben. Bei automatischer Anlage aus Lead, Formular, Email oder Anruf wird ein Default-Verantwortlicher zugewiesen (siehe 2.4 Lead-Routing). [N6, 09.05.2026] 3.1.9 Verknüpfter Hauptkontakt (Pflicht, jeder Verkaufsfall hat einen Ansprechpartner). 3.1.10 Verknüpfte Firma (optional, bei Privatkunden bleibt das Feld leer). 3.1.11 Ursprungs-Lead, falls der Verkaufsfall aus einer Anfrage entstanden ist. 3.1.12 Verlust-Grund, falls der Verkaufsfall verloren wurde, Pflichtfeld in dem Fall. 3.1.13 Tags / Schlagworte zum freien Klassifizieren. 3.1.14 Branchenspezifische Zusatzfelder (zum Beispiel „Anlagen-Typ", „Wärmebedarf in kW", „ist Bestandsanlage", durch den Mandanten konfigurierbar). 3.1.15 Verknüpfung zum Auftragsprojekt. Wann das Auftragsprojekt entsteht, ist mandanten-konfigurierbar (siehe 3.6.7): entweder erst beim Übergang in „Gewonnen" oder bereits bei Anlage des Verkaufsfalls. [N7, 09.05.2026]

3.2 Pipeline-Konfiguration durch den Mandanten

3.2.1 Der Mandant kann mehrere Pipelines parallel betreiben. Geerkens braucht zum Start mindestens zwei: „Anlagen-Verkauf" und „Wartungsverträge". 3.2.2 Jede Pipeline hat einen Namen, eine optionale Beschreibung und eine Markierung „Standard-Pipeline" (eine pro Mandant ist Default für neue Verkaufsfälle ohne explizite Auswahl). 3.2.3 Pipelines werden vom Mandanten-Administrator angelegt, dupliziert, umsortiert oder archiviert. Hard-Delete nur, wenn nie ein Verkaufsfall in der Pipeline war. 3.2.4 Pro Pipeline definiert der Mandant Stufen (zum Beispiel „Anfrage", „Besichtigung", „Bedarfsanalyse", „Angebot", „Verhandlung", „Gewonnen", „Verloren"). 3.2.5 Pro Stufe konfigurierbar: Name, Reihenfolge, Stufen-Typ (offen / gewonnen / verloren), Erfolgs-Wahrscheinlichkeit in Prozent (für die Forecast-Rechnung), optionale Stuck-Schwelle in Tagen, Farbe für visuelle Markierung. 3.2.6 Jede Pipeline muss mindestens eine „Gewonnen"-Stufe und eine „Verloren"-Stufe haben. Beim Speichern ohne diese Stufen erscheint Klartext-Hinweis: „Diese Pipeline hat keine ‚Gewonnen'-Stufe. Bitte mindestens eine Stufe vom Typ ‚gewonnen' anlegen." 3.2.7 Stufen-Reihenfolge wird per Drag & Drop verändert. 3.2.8 Stufe löschen ist blockiert, wenn noch aktive Verkaufsfälle drin sind. Klartext: „In dieser Stufe sind 8 aktive Verkaufsfälle. Bitte zuerst neu zuweisen oder Stufe archivieren statt löschen." 3.2.9 Beim Anlegen eines neuen Mandanten werden die SHK-Standard-Pipelines mit den Standard-Stufen automatisch vorausgefüllt. Der Mandant kann sie behalten, anpassen oder löschen.

3.3 Verlust- und Gewinn-Gründe (durch den Mandanten gepflegt) [N8, 09.05.2026]

3.3.1 Liste der möglichen Verlust-Gründe wird durch den Mandanten-Administrator gepflegt (zum Beispiel „Preis/Leistung", „Konkurrenz übernommen", „Kein Bedarf mehr", „Kein Budget", „Nicht erreicht"). 3.3.2 Liste der möglichen Gewinn-Gründe wird ebenfalls durch den Mandanten-Administrator gepflegt (zum Beispiel „Preis überzeugt", „Empfehlung", „bestehende Kunden-Beziehung", „technische Beratung", „Termin-Zuverlässigkeit"). Bei jeder Gewonnen-Markierung wird der Grund zur Auswahl angeboten. 3.3.3 Beim Anlegen eines Mandanten werden je 5 SHK-typische Standard-Gründe (Verlust und Gewinn) vorausgefüllt. Der Mandant kann sie behalten, ändern, ergänzen oder löschen. 3.3.4 Beide Listen können archiviert, aber nicht hart gelöscht werden, sonst leiden die Auswertungen. 3.3.5 Auswertung pro Grund: wie häufig wurde welcher Verlust- oder Gewinn-Grund vermerkt, gefiltert nach Pipeline, Vertriebler, Zeitraum (für die Vertriebs-Strategie-Diskussion).

3.4 Verkaufsfall-Liste und Spalten-Ansicht (Kanban)

3.4.1 Verkaufsfälle sind in zwei Ansichten verfügbar: als Spalten-Ansicht (Kanban), in der jede Pipeline-Stufe eine Spalte ist, und als Tabellen-Ansicht. 3.4.2 In der Spalten-Ansicht sieht man pro Spalte: Stufen-Name, Anzahl Verkaufsfälle, Summe Volumen, Wahrscheinlichkeit. Pro Karte: Titel, Volumen (sofern berechtigt), Verantwortlicher, erwarteter Abschluss-Termin, Tags, visueller Hinweis bei Überfälligkeit, visueller Hinweis bei „seit zu lange in derselben Stufe" (Stuck-Status). 3.4.3 Verkaufsfälle können per Drag & Drop zwischen Stufen verschoben werden. 3.4.4 Es gibt eine Cross-Pipeline-Sicht, die Verkaufsfälle aus allen Pipelines in einer einzigen Tabelle zeigt. 3.4.5 Suche über Titel, Beschreibung, verknüpfte Kontakt- und Firmen-Namen. 3.4.6 Filter: Verantwortlicher, Tags, Volumen-Spanne, erwarteter Abschluss-Termin, Stufe, Pipeline. 3.4.7 Schnell-Filter „Nur meine Verkaufsfälle". 3.4.8 Sortier- und Spalten-Konfiguration in der Tabellen-Ansicht pro Benutzer speicherbar. 3.4.9 Massen-Aktionen: Tags hinzufügen/entfernen, Verantwortlichen ändern, Stufe wechseln, archivieren. 3.4.10 Export der gefilterten Auswahl als CSV. 3.4.11 Mehrere Benutzer sehen Pipeline-Änderungen anderer in Echtzeit (live-Aktualisierung der Spalten-Ansicht).

3.5 Stufen-Übergänge und Gewonnen / Verloren

3.5.1 Vorwärts- und rückwärts-Wechsel zwischen Stufen ist erlaubt. Bei Rückwärts-Wechsel zeigt das System einen Klartext-Hinweis. 3.5.2 Beim Wechsel in eine „Gewonnen"-Stufe öffnet sich ein Bestätigungs-Dialog mit der Frage „Auftragsprojekt aus diesem Verkaufsfall anlegen?" (siehe Won-Handoff-Abschnitt 3.6). 3.5.3 Beim Wechsel in „Verloren" wird ein Verlust-Grund aus der konfigurierbaren Liste (siehe 3.3) erzwungen. Beim Wechsel in „Gewonnen" wird ein Gewinn-Grund aus der konfigurierbaren Liste angeboten (Pflicht für Auswertung; lässt sich pro Mandant auf optional umschalten). Optional kann der Benutzer in beiden Fällen eine freie Notiz hinterlegen. [N8, 09.05.2026] 3.5.4 Eine Gewonnen- oder Verloren-Markierung kann innerhalb von 24 Stunden zurückgenommen werden. Danach ist sie endgültig. 3.5.5 Pipeline-Wechsel eines Verkaufsfalls (zum Beispiel von „Anlagen-Verkauf" nach „Wartungsverträge") ist möglich, erfordert aber erweiterte Berechtigungen und wird mit Klartext-Hinweis und Eintrag in die Historie versehen. 3.5.6 Jeder Stufen-Wechsel wird nachvollziehbar protokolliert (wer, wann, von welcher Stufe in welche, wie lange war der Verkaufsfall in der vorherigen Stufe).

3.6 Won-Handoff zur Auftragspipeline

3.6.1 Wird ein Verkaufsfall als „Gewonnen" markiert, fragt das System: „Auftragsprojekt aus diesem Verkaufsfall anlegen?", Standard-Antwort „Ja". 3.6.2 Bei „Ja" wird automatisch ein Auftragsprojekt in der Auftragspipeline (Modul 4) angelegt. Übergeben werden: Titel, Volumen, Verantwortlicher, verknüpfter Kontakt und Firma, hochgeladene Dateien, Notizen. 3.6.3 Der Benutzer wählt im Dialog die Ziel-Auftrags-Pipeline (zum Beispiel „Anlagen-Installation") und die Start-Stufe. 3.6.4 Der Verkaufsfall behält die Verknüpfung zum entstandenen Auftragsprojekt. Im Verkaufsfall-Detail erscheint ein Verweis auf das Projekt. 3.6.5 Bei „Nein" wird der Verkaufsfall nur als Gewonnen markiert, ohne Projekt-Anlage. 3.6.6 Aus einem einzigen Verkaufsfall können mehrere Auftragsprojekte entstehen, etwa „PV-Anlage" und „Badumbau" parallel beim selben Kunden. Im Verkaufsfall-Detail kann jederzeit nachträglich ein weiteres Projekt erzeugt oder ein bestehendes Projekt manuell verknüpft werden. Hinweis: Wartungsverträge und einzelne Service-Einsätze sind in HiveGrid keine Projekte, sondern Service. Sie laufen über das Service-Modul (Phase 2, siehe Vision V.3.2.5). [N9, 09.05.2026] 3.6.7 Mandanten-Konfiguration: Wann entsteht das Auftragsprojekt? [N7, 09.05.2026] - Option A: bei Gewonnen-Übergang (Default). Das Projekt wird erst angelegt, wenn der Verkaufsfall als „Gewonnen" markiert ist. Geeignet für Mandanten, die mit einem externen Angebots-Tool (PandaDoc, DocuSign) arbeiten und die Auftragsabwicklung erst nach Vertragsabschluss starten. - Option B: bei Verkaufsfall-Anlage. Das Projekt wird sofort beim Anlegen des Verkaufsfalls automatisch in einer konfigurierbaren Default-Auftrags-Pipeline angelegt und mit dem Verkaufsfall verknüpft. Geeignet für Mandanten, die das Angebot in der ERP (z. B. KWP) erstellen und dort schon eine Projekt-Zuordnung brauchen, bevor der Verkaufsfall gewonnen ist. - Wahl durch den Mandanten-Administrator pro Sales-Pipeline. Wechsel der Option ist später möglich, gilt nur für neue Verkaufsfälle. - Bei Option B mit späterem „Verloren" wird das angelegte Projekt automatisch archiviert (nicht hart gelöscht, damit ERP-Verknüpfungen nicht reißen).

3.7 Mehrere Quellen für neue Verkaufsfälle

3.7.1 Manuelle Anlage über die Sales-Ansicht. 3.7.2 Aus einer Lead-Anfrage (Modul 2) per „Lead in Verkaufsfall umwandeln". Lead-Daten werden in den Verkaufsfall übernommen. 3.7.3 Aus einer Formular-Einsendung (Modul 5), der Mandanten-Administrator konfiguriert pro Formular, welche Felder wie auf einen Verkaufsfall abgebildet werden. 3.7.4 Aus einer Email-Konversation (Modul 9), „Verkaufsfall aus dieser Email anlegen". Das System schlägt den passenden Kontakt automatisch vor. 3.7.5 Aus einem eingegangenen Anruf (Modul 12, AirCall), Anruf-Notiz wird Verkaufsfall-Beschreibung, Telefonnummer wird automatisch dem Kontakt zugeordnet. 3.7.6 Aus einer Automation (Modul 17), zum Beispiel automatisch bei jeder neuen Anfrage aus einer bestimmten Quelle.

3.8 Stuck-Erkennung und Auto-Archivierung

3.8.1 Pro Stufe kann eine Schwellen-Anzahl an Tagen hinterlegt werden. Verkaufsfälle, die länger in dieser Stufe stehen, werden als „liegen geblieben" markiert (visueller Hinweis im Kanban + Banner im Detail). 3.8.2 Tägliche Hintergrund-Prüfung erkennt diese Verkaufsfälle automatisch. 3.8.3 Gewonnen-Verkaufsfälle werden nach 30 Tagen automatisch archiviert (pro Pipeline konfigurierbar). 3.8.4 Verloren-Verkaufsfälle werden nach 90 Tagen automatisch archiviert (pro Pipeline konfigurierbar). 3.8.5 Archivierte Verkaufsfälle bleiben in den Auswertungen und Reports sichtbar, sind aber aus dem Tagesgeschäft ausgeblendet. 3.8.6 Verkaufsfälle können vom Verantwortlichen oder vom Administrator wieder reaktiviert werden.

3.9 Verkaufsfall-Detail-Ansicht

3.9.1 Zeigt alle Stammdaten, Stufen-Historie, Notizen, verknüpfte Aufgaben (Modul 26), Dateien, Formular-Einsendungen, Email-Verlauf, Anrufe und Termine. 3.9.2 Wenn der Verkaufsfall aus einem Lead entstand, erscheint ein Hinweis mit Verweis auf den Ursprungs-Lead. 3.9.3 Aktionen aus dem Detail heraus: anrufen (Click-to-Call), Email schreiben, Termin direkt am Verkaufsfall anlegen (siehe 3.9.5), Aufgabe anlegen, Notiz hinzufügen, Datei hochladen, Formular-Einsendung verknüpfen, Tags pflegen, archivieren. 3.9.5 Termin-Anlage direkt aus dem Verkaufsfall (Setter-Closer-Workflow) [N17, 09.05.2026] - Aus dem Verkaufsfall heraus kann ein Termin für eine andere Person im Mandanten angelegt werden (Use-Case: ein Setter telefoniert mit dem Kunden und plant für den Closer einen Vor-Ort-Termin). - Die Verkaufsfall-Daten werden automatisch in den Termin übernommen, nach einem mandanten-konfigurierbaren festen Layout: Kunde, Adresse, Telefon, Volumen, Anlagen-Typ, Notizen, Verlinkung zurück auf den Verkaufsfall, Verlinkung zu den hochgeladenen Fotos / Dateien. - Mandanten-Administrator definiert pro Sales-Pipeline einmalig, welche Verkaufsfall-Felder in welcher Form in den Termin übernommen werden. Setter muss nichts mehr abtippen. - Der Termin wird über das Kalender-Modul (M25) im Kalender des Closer angelegt und über die Kalender-Synchronisation in seinen Google- oder Microsoft-Kalender geschrieben. - Bei Termin-Verschiebung oder Absage durch den Closer aktualisiert sich der Verlauf am Verkaufsfall automatisch. 3.9.4 Klartext-Banner bei besonderen Zuständen (Beispiele): - „Dieser Verkaufsfall wurde als gewonnen markiert am [Datum]. [Gewonnen-Status zurücknehmen, 24h verfügbar]" - „Dieser Verkaufsfall ist als verloren markiert. Grund: [Grund]. [Wieder öffnen]" - „Dieser Verkaufsfall ist seit X Tagen in der Stufe [Name]. Üblich sind Y Tage. Soll eine Erinnerung erstellt werden?" - „Der zugeordnete Kontakt ist archiviert."

3.10 Forecast und Vertriebs-Kennzahlen

3.10.1 Pro Pipeline und pipelineübergreifend wird ein Forecast berechnet: Summe der Verkaufsfälle gewichtet mit der Wahrscheinlichkeit der jeweiligen Stufe. Beispiel: Ein Verkaufsfall über 25.000 Euro in der Stufe „Verhandlung" mit 70% Wahrscheinlichkeit trägt 17.500 Euro zum Forecast bei. 3.10.2 Aufteilung nach Zeitraum: dieser Monat, dieses Quartal, nächste 12 Monate. 3.10.3 Realisierter Umsatz als Kontrast zum Forecast: Summe aller Gewonnen-Verkaufsfälle im Zeitraum. 3.10.4 Pro Vertriebler werden gezeigt: aktive Verkaufsfälle, Forecast-Beitrag, Gewinn-Quote der letzten 90 Tage, Aktivitäts-Zahlen (Anrufe, Mails, Termine), durchschnittliche Dauer von Anlage bis Gewonnen, Anzahl liegen-gebliebener Verkaufsfälle. 3.10.5 Stufen-Übergangs-Quoten („Wie viele Prozent der Verkaufsfälle, die in Stufe A waren, kommen in Stufe B an?"). 3.10.6 Verteilung der Verlust-Gründe. 3.10.7 Diese Kennzahlen werden im Dashboard-Modul (M20) als Widgets gezeigt.

3.11 Berechtigungen

3.11.1 Es gibt mehrere Berechtigungs-Stufen rund um Verkaufsfälle: nur eigene sehen, alle sehen, anlegen/bearbeiten, Stufen wechseln, löschen, Pipeline-Verwaltung. 3.11.2 Eine eigene Berechtigung gilt für das Volumen-Feld. Das ist wichtig, weil etwa Bauleiter und Monteure den Verkaufsfall als Kontext sehen sollen, aber nicht das Volumen. 3.11.3 Eine eigene Berechtigung gilt für aggregierte Kennzahlen (Forecast, Stufen-Volumen, Performance-Charts). 3.11.4 SHK-Standard-Rollen: Geschäftsführer sieht alles inklusive Volumen und Aggregaten. Vertriebsleiter ebenso. Vertriebler sieht alle Verkaufsfälle, aber Volumen nur bei eigenen. Bauleiter/Projektleiter sehen Verkaufsfälle als Kontext, aber kein Volumen, keine Aggregate. Büro sieht alles inklusive Volumen für Rechnungs-Vorbereitung. Monteur sieht keine Verkaufsfälle. 3.11.5 Zugriff auf einen nicht-erlaubten Verkaufsfall ergibt eine 404-Meldung („nicht gefunden") statt einer 403-Meldung („verboten"), damit nicht erkennbar ist, dass es den Verkaufsfall überhaupt gibt. 3.11.6 Klartext bei Berechtigungs-Fehlern, Beispiele: - „Du darfst Verkaufsfälle nicht in andere Phasen verschieben. Bitte einen Vertriebsleiter." - „Du kannst diesen Verkaufsfall als gewonnen markieren, aber das automatische Anlegen eines Auftragsprojekts erfordert zusätzliche Berechtigung. Möchtest du nur den Gewonnen-Status setzen?"

3.12 Phase 2 / bewusst NICHT in Phase 1

3.12.1 Marge / Deckungsbeitrag pro Verkaufsfall mit eigener Sicht-Berechtigung. 3.12.2 Versionierung von Angeboten zu einem Verkaufsfall. 3.12.3 Konfigurierbare Sichtbarkeit einzelner Zusatzfelder pro Rolle (Phase-2-Feinschliff).

3.13 Klartext-Fehlertexte (Beispiele)

3.13.1 Pipeline ohne Gewonnen-Stufe beim Speichern: „Diese Pipeline hat keine ‚Gewonnen'-Stufe. Bitte mindestens eine Stufe vom Typ ‚gewonnen' anlegen." 3.13.2 Pipeline ohne Verloren-Stufe: „Diese Pipeline hat keine ‚Verloren'-Stufe. Bitte mindestens eine Stufe vom Typ ‚verloren' anlegen." 3.13.3 Stufe löschen mit Verkaufsfällen drin: „In dieser Stufe sind 8 aktive Verkaufsfälle. Bitte zuerst neu zuweisen oder Stufe archivieren statt löschen." 3.13.4 Hard-Delete eines Verkaufsfalls mit angelegtem Auftragsprojekt: „Dieser Verkaufsfall hat ein verknüpftes Projekt. Bitte zuerst Verknüpfung lösen oder Projekt selbst archivieren/löschen."

Modul 4: Auftragspipeline (Projektabwicklung)

Was es tut: Bildet die komplette Abwicklung eines Auftrags ab, vom Übergang aus dem gewonnenen Verkaufsfall über Disposition, Material-Bestellung, Ausführung auf der Baustelle bis zur Abnahme mit Kunden-Unterschrift. Beinhaltet die Plantafel für die Mitarbeiter-Einsatzplanung und das Abnahme-Protokoll mit digitaler Unterschrift. Löst ab: Eigenbau-Excel-Pläne, manuelle Disposition, Papier-Abnahme-Protokolle. Warum es wichtig ist: Das ist der Geerkens-Kern. Hier passiert das eigentliche Tagesgeschäft eines SHK-Betriebs. Ohne dieses Modul gibt es keinen sinnvollen Mehrwert gegenüber HubSpot.

4.1 Was zu einem Auftragsprojekt gespeichert wird

4.1.1 Eindeutige Projekt-Nummer, fortlaufend pro Mandant (Beispiel: „P-2026-0042"). 4.1.2 Titel (Pflicht), längere Beschreibung als Freitext. 4.1.3 Pipeline und aktuelle Stufe (offen / abgeschlossen / storniert). 4.1.4 Volumen (Auftragswert). 4.1.5 Geplanter Start-Termin, geplanter End-Termin, tatsächlicher End-Termin. 4.1.6 Baustellen-Adresse (kann von der Kontakt-Adresse abweichen, Straße, PLZ, Ort, Land). 4.1.7 Hauptverantwortlicher Projektleiter. 4.1.8 Verknüpfter Hauptkontakt (Pflicht). 4.1.9 Verknüpfte Firma (optional). 4.1.10 Ursprungs-Verkaufsfall (optional, Projekte können auch ganz ohne Verkaufsfall angelegt werden, etwa Notfall-Reparaturen oder Wartungstermine). 4.1.11 Eingesetzte Mitarbeiter mit ihrer Rolle im Projekt (Projektleiter, Bauleiter, Monteur, Lehrling, frei beschriftbar). 4.1.12 Tags / Schlagworte. 4.1.13 Branchenspezifische Zusatzfelder. 4.1.14 Stornierungs-Grund (Pflichtfeld, wenn Projekt storniert wurde). 4.1.15 Verknüpftes Projekt-Vorlagen-Muster, falls aus Vorlage angelegt.

4.2 Pipeline-Konfiguration

4.2.1 Wie bei Verkaufsfällen kann der Mandant mehrere Auftrags-Pipelines parallel führen. Geerkens braucht zum Start drei: „Anlagen-Installation", „Wartungseinsatz", „Notfall-Reparatur". 4.2.2 Pro Stufe konfigurierbar: Name, Reihenfolge, Stufen-Typ (offen / abgeschlossen / storniert), Stuck-Schwelle in Tagen, Farbe. 4.2.3 Eine Stufe kann auf „erfordert Abnahme-Protokoll" gestellt werden. Wechsel in diese Stufe ist dann nur möglich, wenn ein gültiges Abnahme-Protokoll vorliegt. 4.2.4 Pro Stufe mit Abnahme-Pflicht muss ein Abnahme-Formular-Muster zugewiesen sein (siehe Abschnitt 4.7). 4.2.5 Beim Anlegen eines Mandanten werden die SHK-Standard-Pipelines mit ihren Stufen vorausgefüllt: - Anlagen-Installation: Vorbereitung → Disposition/Materialbestellung → Ausführung → Abnahme (Abnahme-Pflicht) → Abgeschlossen → Storniert. - Wartungseinsatz: Termin geplant → In Ausführung → Abgeschlossen → Storniert. - Notfall-Reparatur: Eingegangen → Unterwegs → Vor Ort → Abgeschlossen. 4.2.6 Pipeline muss mindestens eine „Abgeschlossen"-Stufe haben.

4.3 Projekt-Vorlagen

4.3.1 Der Mandanten-Administrator kann Projekt-Vorlagen anlegen (zum Beispiel „Standard-Anlagen-Installation"). 4.3.2 Eine Vorlage enthält: Default-Pipeline, Default-Start-Stufe, Default-Mitarbeiter-Rollen, Default-Aufgaben, Default-Plantafel-Einträge (zum Beispiel „3 Tage Vorbereitung + 2 Tage Installation + 1 Tag Abnahme"), Default-Zusatzfelder. 4.3.3 Beim Anlegen eines neuen Projekts kann eine Vorlage gewählt werden, die genannten Vorbelegungen werden automatisch übernommen und können angepasst werden.

4.4 Quellen für neue Auftragsprojekte

4.4.1 Manuelle Anlage über die Auftrags-Ansicht. 4.4.2 Automatisch aus einem gewonnenen Verkaufsfall (Won-Handoff, siehe Modul 3 Abschnitt 3.6). 4.4.3 Mehrfach-Anlage aus demselben Verkaufsfall (zum Beispiel ein Anlagen-Installations-Projekt plus ein Wartungs-Projekt aus dem gleichen Verkauf). 4.4.4 Aus einer Formular-Einsendung (Modul 5), zum Beispiel ein Service-Anfrage-Formular legt automatisch ein Projekt in der „Wartungseinsatz"-Pipeline an. 4.4.5 Aus einer Termin-Buchung (Modul 6), Wartungstermin-Buchung erzeugt automatisch ein Projekt plus einen passenden Plantafel-Eintrag. 4.4.6 Aus einem Notfall-Anruf (Modul 12, AirCall), Funktion „Notfall-Auftrag aus diesem Anruf anlegen". 4.4.7 Aus einer Automation (Modul 17). 4.4.8 Aus einer Vorlage (siehe 4.3).

4.5 Spalten- und Tabellen-Ansicht

4.5.1 Wie bei Verkaufsfällen: Spalten-Ansicht (Kanban) pro Pipeline, plus Tabellen-Ansicht. 4.5.2 Pro Karte: Projekt-Nummer, Titel, Volumen (sofern berechtigt), Mitarbeiter (Avatare, Projektleiter hervorgehoben), Zeitraum, visueller Hinweis bei Stuck oder Überzogenem End-Termin, visueller Hinweis bei offenen Mängeln aus einer Abnahme, Tags, Kontakt-Name, Kurz-Adresse. 4.5.3 Drag & Drop zwischen Stufen. Beim Drag in eine Stufe mit Abnahme-Pflicht erscheint Klartext-Block: „Diese Stufe erfordert ein Abnahmeprotokoll. [Abnahme starten]". 4.5.4 Beim Drag in „Abgeschlossen" wird optional der tatsächliche End-Termin erfragt. 4.5.5 Beim Drag in „Storniert" wird der Stornierungs-Grund erzwungen.

4.6 Plantafel (Mitarbeiter-Einsatzplanung)

Erweiterung gem. Anmerkung Noah, 09.05.2026 [N10]: Die Plantafel ist bei vielen Mandanten ein zentral genutztes Werkzeug der ERP-Welt. Bei Geerkens läuft sie heute überwiegend in KWP, weil dort auch Service-Einsätze mit-disponiert werden. HiveGrid darf hier keine Insel werden. Anforderung: bidirektionale Synchronisation zwischen KWP-Plantafel und HiveGrid-Plantafel. Beide Seiten lesen UND schreiben. Der Mandant entscheidet selbst, ob er die Plantafel primär in KWP oder in HiveGrid pflegt. Detail-Anforderungen siehe 4.6.14.

4.6.1 Die Plantafel ist eine Wochenkalender-Funktion, die zeigt, welcher Mitarbeiter wann an welchem Projekt arbeitet. 4.6.2 Senkrechte Achse: Mitarbeiter-Liste. Waagerechte Achse: Zeitraum (umschaltbar zwischen Tag, Woche, Monat). 4.6.3 Im Raster werden Einsatz-Blöcke gezeigt, pro Block: Projekt-Titel, Status, Kurz-Adresse, Farbe nach Pipeline. 4.6.4 Drag & Drop: Einsatz-Blöcke können verschoben, in der Länge angepasst oder neu angelegt werden (Klick auf einen leeren Slot). 4.6.5 Optional einblendbar: Urlaube und Krankmeldungen aus dem HR-Hub (Modul 14), externe Kalender-Termine (Modul 25), Verfügbarkeits-Regeln pro Mitarbeiter. 4.6.6 Filter: Mitarbeiter (Rolle, Gruppe, Verfügbarkeit), Projekt (Pipeline, Stufe, Tag, Status). 4.6.7 Massen-Aktion „neu zuweisen" (zum Beispiel bei Krankheits-Vertretung). 4.6.8 Anlage aus einer Projekt-Vorlage übernimmt die Default-Einsatz-Blöcke.

4.6.9 Konflikt-Erkennung mit Klartext-Hinweisen

4.6.9.1 Doppel-Belegung: roter Indikator + „Max ist Mo 10-14 schon im Projekt P-2026-0042 verplant. Trotzdem zuweisen?" 4.6.9.2 Genehmigter Urlaub: „Max hat am Dienstag genehmigten Urlaub. Trotzdem zuweisen?" 4.6.9.3 Krankmeldung: „Max ist seit gestern krankgemeldet. Trotzdem einplanen?" 4.6.9.4 Außerhalb der Verfügbarkeits-Regeln: „Max arbeitet normalerweise nur Mo-Do. Trotzdem für Freitag einplanen?" 4.6.9.5 Außerhalb Arbeitszeit: „Slot ist um 22:00, außerhalb der üblichen Arbeitszeit. Bestätigen?"

4.6.10 Verfügbarkeits-Regeln pro Mitarbeiter

4.6.10.1 Pro Mitarbeiter konfigurierbar: Standard-Wochenarbeitszeit, Pausen-Zeiten, Ausnahmen. 4.6.10.2 Verfügbarkeits-Regeln werden bei der Konflikt-Erkennung der Plantafel berücksichtigt.

4.6.11 Status-Verlauf eines Plantafel-Eintrags

4.6.11.1 Status-Stufen: geplant → bestätigt → in Arbeit → erledigt (oder abgesagt). 4.6.11.2 Statuswechsel kann durch den Mitarbeiter selbst getätigt werden (Mobile-Funktion).

4.6.12 Abgleich mit dem persönlichen Kalender des Mitarbeiters

4.6.12.1 Plantafel-Einträge werden automatisch in den persönlichen Google- oder Microsoft-Kalender des Mitarbeiters synchronisiert (Modul 25). 4.6.12.2 Sagt der Mitarbeiter den Termin in seinem Kalender ab, wird der Status auf „abgesagt" gesetzt und der Projektleiter benachrichtigt.

4.6.13 Mobile Sicht für den Monteur

4.6.13.1 Die Plantafel selbst ist Desktop-Funktion (für die Disposition im Büro). 4.6.13.2 Der Monteur sieht stattdessen auf dem Handy eine vereinfachte „Meine Termine heute"-Liste mit allen heutigen Einsätzen. 4.6.13.3 Pro Termin: Projekt-Titel, Adresse mit Karten- und Navigations-Verknüpfung, Notiz, Status, einfacher Knopf zum Statuswechsel (bestätigt → in Arbeit → erledigt). 4.6.13.4 Zusätzlich „Meine Woche"-Übersicht. 4.6.13.5 Push-Benachrichtigung bei neuer Zuweisung oder Änderung.

4.6.14 Bidirektionale Synchronisation mit der KWP-Plantafel [N10, 09.05.2026]

4.6.14.1 Was synchronisiert wird: Termine (Einsatz-Blöcke) mit Mitarbeiter-Zuweisung, Datum, Zeitfenster, Projektnummer (oder KWP-Service-Nummer), Adresse, Status. Beide Seiten lesen UND schreiben. 4.6.14.2 Quellen-Abgleich: jeder Termin hat eine eindeutige System-übergreifende ID. Wird ein Termin in KWP angelegt, kommt er mit der KWP-ID nach HiveGrid; umgekehrt vergibt HiveGrid eine ID, die KWP übernimmt. So kann jede Seite den Termin der jeweils anderen wiedererkennen. 4.6.14.3 Sync-Frequenz: Push (Echtzeit) wo technisch möglich, Pull-Fallback alle 5 Minuten als Backup. Verzögerung im Schnitt unter 30 Sekunden. 4.6.14.4 Wahl der Primär-Welt durch den Mandanten: der Mandanten-Administrator legt fest, ob die Disposition primär in KWP oder primär in HiveGrid passiert. Beide Modi sind möglich, beide Seiten bleiben schreibfähig. Diese Einstellung beeinflusst nur die Default-Ansicht und die Konflikt-Auflösungs-Regel (siehe 4.6.14.7). 4.6.14.5 Service-Einsätze (Wartungen, Reparaturen) aus KWP: wenn KWP Service-Termine für Mitarbeiter plant, die in HiveGrid keine Projekt-Zuordnung haben, werden diese Termine in HiveGrid als „Service-Einsatz aus KWP" gekennzeichnet sichtbar (zur Vermeidung von Doppel-Disposition). Sobald HiveGrid ein eigenes Service-Modul bekommt (Phase 2, siehe Vision V.3.2.5), werden Service-Einsätze in dieses Modul integriert. 4.6.14.6 Konflikt-Erkennung: wird derselbe Termin gleichzeitig in beiden Systemen geändert (z. B. KWP verschiebt um 1 Stunde, HiveGrid wechselt den Mitarbeiter), wird der Konflikt im Audit-Log markiert und der Mandanten-Administrator bekommt Klartext-Notification: „Termin am [Datum] wurde gleichzeitig in KWP und HiveGrid geändert. Bitte prüfen, welcher Stand gilt." 4.6.14.7 Konflikt-Auflösungs-Regel: Default ist „KWP gewinnt" (konsistent mit 19.6, da KWP System-of-Record für Buchhaltung und Service ist). Pro Mandant umstellbar auf „HiveGrid gewinnt" oder „manuelle Bestätigung erforderlich". 4.6.14.8 Plantafel-getriebene Automatisierungen (HiveGrid-Stärke): Termine aus der Plantafel können Auslöser für Automatisierungen sein (Modul 17). Beispiele: Termin-Erinnerung 1 Tag vorher per WhatsApp/SMS an den Endkunden, Status-Update an den Endkunden bei Verschiebung, automatische Rückmeldung an das Kunden-Portal bei „erledigt". Das ist ein Funktions-Vorteil, der KWP nicht hat. 4.6.14.9 Anti-Endlosschleife: ein Termin, der durch den Sync von KWP nach HiveGrid übertragen wird, löst keinen Push zurück nach KWP aus. Sync-Status ist pro Termin sichtbar („zuletzt synchronisiert um [Zeit] aus KWP" / „nach KWP geschickt um [Zeit]").

4.7 Abnahme-Workflow

4.7.1 Abnahme-Protokoll-Formulare sind durch den Mandanten-Administrator konfigurierbar (basieren auf dem Formular-Baukasten Modul 5). 4.7.2 Beim Anlegen eines Mandanten wird ein SHK-Standard-Abnahme-Formular vorausgefüllt mit: Datum/Uhrzeit der Abnahme, Anwesende mit Rollen, Druckprobe-Boolean + Wert, Funktionsprüfung Heizkreis, Wärmemengenzähler-Werte, Inbetriebnahme-Datum, Garantie-Beginn, übergebene Dokumente (Bedienungsanleitung, Garantiekarte, Wartungs-Termin-Übersicht), Mängel-Liste mit Foto-Anhängen, allgemeine Foto-Anhänge, Bemerkungen Kunde, Bemerkungen Monteur. 4.7.3 Eine Abnahme wird vom Monteur mobil auf der Baustelle durchgeführt. Die Anwendung ist mobile-first optimiert.

4.7.4 Schritte einer Abnahme

4.7.4.1 Formular ausfüllen: Felder werden ausgefüllt, Fotos können direkt aus der Kamera hochgeladen werden, Mängel werden mit Foto-Anhang erfasst, lange Bemerkungen können diktiert werden (Whisper-Transkription, Modul 18). 4.7.4.2 Mängel-Klassifizierung: pro Mangel wird gewählt: kritisch (Abnahme verweigert) / kleinere Mängel (Abnahme mit Vorbehalt) / kosmetisch (Abnahme erfolgt). Damit ergibt sich der Abnahme-Typ: vollständig / mit Vorbehalt / abgelehnt. 4.7.4.3 Kunde unterschreibt: direkte Touch-Unterschrift auf dem Bildschirm. Kunden-Name wird eingegeben (kann vom hinterlegten Kontakt abweichen). IP-Adresse und Zeitstempel werden automatisch festgehalten. 4.7.4.4 Mitarbeiter unterschreibt: Touch-Unterschrift des Monteurs. 4.7.4.5 Bestätigung: Abnahme-Protokoll wird gespeichert, automatisch wird ein PDF erzeugt (im Dateien-Bereich des Projekts und im Kunden-Portal sichtbar). 4.7.4.6 Auto-Email an den Kunden: Klartext-Email mit dem Protokoll-PDF im Anhang (Vorlage durch Mandant anpassbar).

4.7.5 Folge-Aktionen je nach Abnahme-Typ

4.7.5.1 Vollständig: Projekt wechselt automatisch in „Abgeschlossen" (oder die nächste konfigurierte Stufe). 4.7.5.2 Mit Vorbehalt (kleinere Mängel): Projekt bleibt in „Abnahme", erkannte Mängel werden automatisch als Aufgaben (Modul 26) angelegt mit einer Standard-Frist. 4.7.5.3 Abgelehnt: Projekt fällt zurück in „Ausführung", Projektleiter wird benachrichtigt.

4.7.6 Mehrere Abnahmen pro Projekt

4.7.6.1 Bei großen Aufträgen sind Teilabnahmen möglich. Ein Projekt hat 0 bis beliebig viele Abnahme-Protokolle. 4.7.6.2 Die letzte vollständige Abnahme bestimmt den Projekt-Status.

4.7.7 Klartext-Hinweise und rechtliche Pflicht-Aufbewahrung

4.7.7.1 Abnahme ohne Kunden-Unterschrift wird blockiert: „Bitte Kunden-Unterschrift einholen, sonst keine rechtsgültige Abnahme." 4.7.7.2 Mängel ohne Beschreibung werden blockiert: „Mindestens ein Mangel angekreuzt aber keine Beschreibung. Bitte Mängel detailliert beschreiben." 4.7.7.3 Abnahme-Protokolle sind rechtlich aufbewahrungspflichtig (mindestens 6 Jahre) und können daher nicht gelöscht, sondern nur archiviert werden. 4.7.7.4 IP-Adresse, Zeitstempel und Unterschriften-Bilder werden mit aufbewahrt.

4.8 Projekt-Detail-Ansicht

4.8.1 Zeigt alle Stammdaten, Mitarbeiter-Liste, eingeplante Plantafel-Einträge, verknüpfte Aufgaben (Modul 26), Dateien (inklusive Fotos von der Baustelle), Formular-Einsendungen, alle Abnahme-Protokolle, Verlaufs-Strom (wer hat wann was gemacht), Stufen-Historie. 4.8.2 Bei Projekten mit Adresse wird optional eine Karten-Ansicht angeboten. 4.8.3 Mobile-Ansicht (für den Monteur auf der Baustelle, gemäß Leitplanke 2): - Vereinfachte Stammdaten oben. - Heutige Aufgaben im Vordergrund. - Großer Knopf für Foto-Direkt-Upload. - Großer Knopf für „Abnahme starten". - Großer Knopf für „Notiz diktieren". - Aufgaben mit einfachem Tipp-Wechsel auf erledigt. - Plantafel und Zusatzfelder reduziert dargestellt.

4.8.4 Sales-Verlauf-Sektion (read-only)

4.8.4.1 Wenn das Projekt aus einem Verkaufsfall entstanden ist, zeigt eine eigene Sektion den Sales-Verlauf: Verkaufsfall-Daten zum Zeitpunkt des Won-Handoffs (Volumen, durchlaufene Stufen, Gewonnen-Datum, Lead-Ursprung), Aktivitäts-Strom des Verkaufsfalls (Anrufe, Mails, Notizen, Stufen-Wechsel), Dateien aus der Sales-Phase (Angebot-PDF, Voraufnahme-Fotos, Skizzen), Formular-Einsendungen aus der Sales-Phase. 4.8.4.2 Diese Daten sind nur lesbar im Projekt-Kontext. Klartext-Hinweis: „Diese Daten stammen aus dem Sales-Prozess. Editieren bitte im Verkaufsfall: [D-2026-0042]". 4.8.4.3 Hat der Benutzer keine Berechtigung, den Verkaufsfall zu sehen, wird der Sales-Verlauf einfach nicht angezeigt. 4.8.4.4 Volumen-Berechtigungen aus Modul 3 wirken auch hier, ein Bauleiter ohne Volumen-Berechtigung sieht in der Sales-Verlauf-Sektion das Volumen verborgen.

4.9 Projekt-Lebenszyklus

4.9.1 Vorwärts/Rückwärts-Wechsel zwischen Stufen erlaubt (bei Rückwärts mit Klartext-Hinweis). 4.9.2 Wechsel in Stufe mit Abnahme-Pflicht: blockiert ohne gültiges Abnahme-Protokoll. 4.9.3 Wechsel in „Abgeschlossen": tatsächlicher End-Termin wird optional erfasst. 4.9.4 Wechsel in „Storniert": Stornierungs-Grund Pflicht. 4.9.5 Rücknahme von Abgeschlossen/Storniert nur innerhalb von 24 Stunden möglich. 4.9.6 Auto-Archivierung: abgeschlossen nach 90 Tagen, storniert nach 30 Tagen (pro Pipeline konfigurierbar). Archivierte Projekte bleiben in Reports sichtbar. 4.9.7 Stuck-Erkennung wie bei Verkaufsfällen. 4.9.8 Hard-Delete blockiert, wenn Abnahme-Protokolle hängen, wegen rechtlicher Aufbewahrung. Klartext: „Dieses Projekt hat 2 Abnahme-Protokolle und 14 verknüpfte Dateien (rechtlich aufbewahrungspflichtig). Hard-Delete blockiert. Bitte archivieren statt löschen."

4.10 Mitarbeiter-Verwaltung im Projekt

4.10.1 Pro Projekt können beliebig viele Mitarbeiter zugewiesen werden, jeweils mit einer Rolle (Projektleiter, Bauleiter, Monteur, Lehrling, Rollen frei beschriftbar). 4.10.2 Mitarbeiter können einzeln oder als ganze Gruppe (zum Beispiel „Team Süd") hinzugefügt werden. 4.10.3 Beim Hinzufügen werden die Mitarbeiter automatisch zum Mitglied im Projekt-Team-Chat (Modul 13) hinzugefügt, der Chat-Channel wird beim Anlegen des Projekts automatisch erstellt. 4.10.4 Hinweis bei Projekten ohne Mitarbeiter: „Diesem Projekt sind keine Mitarbeiter zugewiesen. [Mitarbeiter hinzufügen]".

4.11 Berechtigungen

4.11.1 Berechtigungs-Stufen: nur Projekte sehen, in denen ich Mitglied bin / nur Projekte als Projektleiter / alle Projekte / nur aktive Projekte (für Monteure ohne Archiv-Zugriff) / anlegen / bearbeiten / Mitarbeiter verwalten / Stufen wechseln / löschen / administrative Pipeline-Verwaltung. 4.11.2 Volumen-Berechtigung getrennt (eigene/alle/keine). 4.11.3 Aggregierte Kennzahlen-Berechtigung getrennt. 4.11.4 Plantafel-Berechtigungen getrennt: nur eigene Slots sehen / komplette Plantafel sehen / Plantafel-Schreiben (typisch Projektleiter und Disposition) / Massen-Neu-Zuweisung (typisch Administrator). 4.11.5 Abnahme-Berechtigungen getrennt: Abnahme starten und ausfüllen / Abnahme nur lesen / Abnahme-Formular-Vorlagen verwalten. 4.11.6 SHK-Standard-Rollen: Geschäftsführer voll. Vertriebsleiter und Vertriebler sehen alle Projekte (kein Volumen-Detail). Projektleiter/Bauleiter sehen alle, dürfen anlegen, bearbeiten, Plantafel pflegen. Büro/Backoffice sehen alle, dürfen anlegen, lesen Plantafel. Marketing nur lesen ohne Volumen. Monteur sieht nur die Projekte, in denen er Mitglied ist, nur aktive (keine archivierten), kein Volumen, darf für seine eigenen Projekte aber Abnahmen durchführen.

4.12 Integration mit anderen Modulen

4.12.1 Modul 1 CRM: Kontakt und Firma verlinkt; Aktivitäts-Strom auch im Kontakt sichtbar. 4.12.2 Modul 3 Sales-Pipeline: Won-Handoff, Mehrfach-Anlage aus einem Verkaufsfall, Sales-Verlauf-Sektion. 4.12.3 Modul 5 Formulare: Abnahme-Formulare, Foto-Checklisten, Sales-Aufnahme-Formulare wandern aus dem Verkaufsfall mit, Projekt-Anlage aus Formular. 4.12.4 Modul 6 Buchungen: Wartungstermin-Buchung erzeugt automatisch ein Projekt plus Plantafel-Eintrag. 4.12.5 Modul 9 Email: Mails an den Kontakt erscheinen im Projekt-Strom; Auto-Verknüpfung über Betreff-Muster [P-2026-0042]. 4.12.6 Modul 12 Telefonie: Click-to-Call aus dem Projekt heraus; Notfall-Auftrag aus eingehendem Anruf. 4.12.7 Modul 13 Team-Chat: automatischer Projekt-Channel mit allen Mitgliedern; wird bei Projekt-Abschluss archiviert. 4.12.8 Modul 14 HR-Hub: Urlaube und Krankmeldungen fließen in die Plantafel-Konflikt-Erkennung. 4.12.9 Modul 15 Kunden-Portal: Kunde sieht den Projekt-Status (durch Mandant konfigurierbar), Abnahme-PDF wird automatisch freigegeben, Status-Mails bei Stufenwechsel. 4.12.10 Modul 17 Automation: Projekte können durch Automationen angelegt, weitergeschoben oder mit Mitarbeitern besetzt werden; Trigger bei Projekt-Anlage, Stufenwechsel, Abschluss, Stornierung, Mitarbeiter-Wechsel, Abnahme-Abschluss, Plantafel-Änderung. 4.12.11 Modul 19 KWP: optional automatischer Sync zu KWP bei Projekt-Anlage aus gewonnenem Verkaufsfall; Stufenwechsel auf „Abgeschlossen" triggert optional die Rechnungs-Bereitschaft. Über die einheitliche Adapter-Schicht (Leitplanke 11). 4.12.12 Modul 22 Benachrichtigungen: Push an Mitarbeiter bei neuer Zuweisung; Push an Projektleiter bei Mängeln aus Abnahme; Push an Kunde bei Statuswechsel (über Kunden-Portal). 4.12.13 Modul 23 Dateien: Projekt hat eigenen Datei-Bereich; Foto-Direkt-Upload vom Handy; Abnahme-PDF wird hier abgelegt. 4.12.14 Modul 25 Kalender-Sync: Plantafel-Einträge werden in die Kalender der Mitarbeiter synchronisiert. 4.12.15 Modul 26 Aufgaben: Aufgaben mit Projekt verknüpft; Mängel aus Abnahme werden automatisch als Aufgaben angelegt; Default-Aufgaben aus Projekt-Vorlagen.

4.13 Phase 2 / bewusst NICHT in Phase 1

4.13.1 Eigene Rechnungs-Erzeugung in HiveGrid (geht über KWP). 4.13.2 Hardware-gestützte digitale Signatur (eIDAS-konform), Phase 1 reicht Touch-Unterschrift. 4.13.3 Detaillierte Material-Bestell-Verwaltung pro Projekt (Phase 2, falls KWP nicht genügt).

4.14 Klartext-Fehlertexte (Beispiele)

4.14.1 Drag in Stufe mit Abnahme-Pflicht ohne Protokoll: „Diese Stufe erfordert ein Abnahmeprotokoll. [Abnahme starten]" 4.14.2 Plantafel-Schreiben ohne Berechtigung: „Du kannst die Plantafel sehen, aber nicht ändern. Bitte den Projektleiter oder die Disposition kontaktieren." 4.14.3 Abnahme-Start ohne Berechtigung: „Du darfst keine Abnahme starten. Bitte einen Projektleiter oder Bauleiter." 4.14.4 Hard-Delete bei aufbewahrungspflichtigen Daten: siehe 4.9.8. 4.14.5 Stage „Abnahme" ohne zugewiesenes Formular-Muster: „Stufe ‚Abnahme' verlangt Abnahme-Protokoll, aber kein Formular ist zugewiesen. Bitte Formular auswählen oder Pflicht deaktivieren."

Modul 26: Aufgaben

Was es tut: Bietet ein leichtgewichtiges Aufgaben-Modul, das quer zu allen anderen Modulen liegt. Aufgaben können mit Verkaufsfällen, Projekten, Kontakten, Firmen oder Leads verknüpft sein und entstehen manuell, aus Chat-Nachrichten, aus Formular-Einsendungen oder aus Automationen. Löst ab: Manuelle Notizzettel, Outlook-Aufgaben, vereinzelt Asana/Trello. Warum es wichtig ist: Ohne ein gemeinsames Aufgaben-Modul gehen To-dos in Email-Postfächern und Chat-Verläufen verloren. Aufgaben sind die kleinste Arbeits-Einheit, die Vertrieb und Auftrag verbinden.

26.1 Was zu einer Aufgabe gespeichert wird

26.1.1 Titel (Pflicht). 26.1.2 Beschreibung als Freitext (optional). 26.1.3 Verantwortlicher: entweder eine konkrete Person oder eine ganze Gruppe (eines von beiden ist Pflicht). Aufgaben ohne Verantwortlichen sind nicht erlaubt; bei Anlage wird automatisch der Ersteller eingetragen. 26.1.4 Frist / Fälligkeits-Datum (optional). 26.1.5 Priorität: niedrig / normal / hoch / dringend (Standard: normal). 26.1.6 Status: offen / in Arbeit / erledigt. 26.1.7 Erledigt-Datum und Erledigt-von (werden beim Übergang auf erledigt gesetzt). 26.1.8 Verknüpfung zur Haupt-Entität (Kontakt / Firma / Lead / Verkaufsfall / Projekt, optional eines davon). 26.1.9 Quelle der Aufgabe: manuell / aus Chat-Nachricht / aus Formular-Einsendung / aus Automation. 26.1.10 Beobachter-Liste, User, die Benachrichtigungen erhalten, ohne Verantwortlicher zu sein. Der Ersteller wird automatisch Beobachter, wenn er nicht selbst Verantwortlicher ist.

26.2 Listen-Ansichten

26.2.1 „Meine Aufgaben" als Standard-Ansicht: alle Aufgaben, in denen der User Verantwortlicher ist (oder Mitglied der zugewiesenen Gruppe). 26.2.2 „Von mir erstellt" als Filter. 26.2.3 „Alle Aufgaben im Mandanten" mit entsprechender Berechtigung. 26.2.4 Pro Eintrag werden gezeigt: Titel, Priorität (visuell), Frist (relativ wenn ≤ 7 Tage, sonst absolut, Markierung wenn überfällig), verknüpfte Entität (klickbar), Verantwortlicher, Status, Quelle (visueller Hinweis bei Chat / Formular / Automation). 26.2.5 Schnell-Aktionen pro Eintrag: auf erledigt setzen, Priorität ändern, Frist ändern. 26.2.6 Suche über Titel und Beschreibung. 26.2.7 Filter: Status, Priorität, Frist (heute / diese Woche / überfällig / kein Datum), Verknüpfungs-Typ, Quelle. 26.2.8 Schalter „Archivierte anzeigen". 26.2.9 Standard-Sortierung: Frist aufsteigend, dann Priorität. 26.2.10 Massen-Aktionen: Status ändern, Priorität ändern, Verantwortlichen ändern, archivieren, löschen.

26.3 Aufgaben-Verknüpfungen mit anderen Entitäten

26.3.1 Kontakt-, Firmen-, Lead-, Verkaufsfall- und Projekt-Detailansichten haben jeweils einen Aufgaben-Bereich, der die verknüpften Aufgaben zeigt. 26.3.2 Direkt aus diesen Ansichten kann eine neue Aufgabe angelegt werden, die Verknüpfung wird automatisch vorausgefüllt. 26.3.3 Wird die verknüpfte Entität gelöscht, erscheint Klartext-Hinweis: „Die verknüpfte [Entität] wurde gelöscht. [Verknüpfung entfernen]".

26.4 Aufgaben-Detail

26.4.1 Zeigt alle Stammdaten, Verlaufs-Strom (wer hat wann was geändert), Beobachter, Quelle mit Verknüpfung zum Ursprung (zur Chat-Nachricht / zur Formular-Einsendung / zur Automation-Regel). 26.4.2 Aktionen: Stammdaten bearbeiten, Status ändern, Verantwortlichen wechseln, Verknüpfung anlegen/entfernen/ändern, Beobachter pflegen, duplizieren, löschen. 26.4.3 Klartext-Hinweise: - „Diese Aufgabe ist seit X Tagen überfällig." - „Zugewiesener Mitarbeiter ist nicht mehr aktiv. Bitte neu zuweisen." - „Erledigt, wird in 30 Tagen automatisch archiviert."

26.5 Quellen für neue Aufgaben

26.5.1 Manuell über die Aufgaben-Ansicht oder aus jeder Entität-Detailansicht heraus. 26.5.2 Aus einer Chat-Nachricht (Modul 13): Kontext-Menü an einer Nachricht → „Als Aufgabe markieren". Vorausgefüllt werden: Titel (erste 80 Zeichen der Nachricht), Beschreibung (volle Nachricht), Verknüpfung (Projekt / Verkaufsfall / Kontakt des Channels), Verantwortlicher (aktueller User). Im Chat erscheint danach ein Eintrag: „[User] hat eine Aufgabe aus dieser Nachricht erstellt: [Titel]". 26.5.3 Aus einer Formular-Einsendung (Modul 5): pro Formular kann eine Aktion „Aufgabe erstellen" konfiguriert werden, mit Verantwortlichem (Person oder Gruppe), Priorität, Fristen-Berechnung (zum Beispiel „heute + 3 Tage"), Titel-Vorlage und Beschreibungs-Vorlage mit Platzhaltern aus den Formular-Feldern. 26.5.4 Aus einer Automation (Modul 17): Automation-Aktion „Aufgabe erstellen" mit gleichen Parametern wie Formular-Aktion.

26.6 Erinnerungen und Auto-Archivierung

26.6.1 Pro Aufgabe mit Frist werden automatisch Erinnerungen versendet: 24 Stunden vor Frist (Push + In-App), bei Frist (Push + In-App), 24 Stunden nach Frist falls noch offen (Push + In-App + Email als Eskalation). 26.6.2 Empfänger sind der Verantwortliche (oder alle Mitglieder der zugewiesenen Gruppe) plus die Beobachter. 26.6.3 Pro User konfigurierbar: Erinnerungen aktiv/aus, Ruhezeiten werden berücksichtigt, mehrere Erinnerungen werden gebündelt (max. 1 pro 4 Stunden pro User). 26.6.4 Beispiel-Texte: „Die Aufgabe ‚Angebot an Schmidt schicken' ist morgen fällig", „… ist heute fällig", „… ist seit 1 Tag überfällig". 26.6.5 Erledigte Aufgaben werden nach 30 Tagen automatisch archiviert (Standard, eventuell pro Mandant konfigurierbar). 26.6.6 Hinweis beim Erledigen: „Aufgabe erledigt, wird in 30 Tagen automatisch archiviert." 26.6.7 Hard-Delete erst manuell oder über DSGVO-Workflows (Modul 35).

26.7 Verlaufs-Strom-Integration

26.7.1 Folgende Aktivitäten werden im Strom protokolliert: Anlage (mit Quellen-Hinweis), Verantwortlichen-Wechsel, Erledigt-Setzen, Wieder-Öffnen, Frist-Änderung, Priorität-Änderung, Auto-Archivierung. 26.7.2 Aufgaben-Aktivitäten erscheinen automatisch im Verlaufs-Strom der verknüpften Entität (Kontakt / Verkaufsfall / Projekt usw.). 26.7.3 Beispiel-Klartext: „Max Mustermann hat die Aufgabe ‚Angebot an Schmidt schicken' erstellt", „Lisa Müller hat die Aufgabe von Max Mustermann zu sich genommen", „Automation ‚Lead-Eingang' hat eine Aufgabe für Vertrieb-Team erstellt".

26.8 Berechtigungen

26.8.1 Berechtigungs-Stufen: nur eigene Aufgaben sehen / alle sehen / anlegen und bearbeiten / administrative Verwaltung (alle bearbeiten/löschen, Massen-Aktionen, Auto-Archivierungs-Einstellungen). 26.8.2 Eine Aufgabe gilt als „eigen", wenn der User Verantwortlicher, Mitglied der zugewiesenen Gruppe, Ersteller oder Beobachter ist. 26.8.3 Bei Zugriffsversuch auf eine fremde Aufgabe ohne Berechtigung: 404 (nicht gefunden), nicht 403 (verboten). 26.8.4 Aktions-Knöpfe ohne Berechtigung werden gar nicht angezeigt; Massen-Aktionen ohne Berechtigung sind grau mit Tooltip „Hierfür benötigst du erweiterte Berechtigungen".

26.9 Mobile-Sichtbarkeit (Baustellen-Modus)

26.9.1 Die Aufgaben-Liste muss in beiden UI-Modi (Büro/Desktop und Baustelle/Mobile) gut funktionieren. 26.9.2 Auf dem Handy sieht der Monteur „Meine Aufgaben" prominent und kann mit einem einfachen Tipp eine Aufgabe als erledigt markieren.

26.10 Synchronisation mit ERP-Aufgaben-Welt (KWP-Box und vergleichbare) [N11, 09.05.2026]

Erweiterung gem. Anmerkung Noah, 09.05.2026: Viele ERPs (bei Geerkens KWP mit der „KWP-Box" / Aktivitätsmanagement) bieten bereits projektbezogene Tickets/Aufgaben. Geerkens nutzt das vollumfänglich. Ein zweites Aufgaben-Tool in HiveGrid würde Doppelpflege erzeugen. Anforderung: HiveGrid-Aufgaben können mit ERP-Aufgaben gespiegelt werden, modular konfigurierbar, ohne dass sich die Systeme gegenseitig aushebeln.

26.10.1 Pro Mandant aktivierbar: die ERP-Aufgaben-Synchronisation wird vom Mandanten-Administrator pro angebundenem ERP-Adapter (KWP, später Taifun, TopKontor, Streit V.1) ein- und ausgeschaltet. Mandanten ohne ERP-Sync nutzen das Aufgaben-Modul rein in HiveGrid wie bisher beschrieben. 26.10.2 Identifikations-Brücke: Aufgaben werden über die Projektnummer zwischen den Systemen verknüpft. Bei KWP-Box läuft das technisch über die Email-Adresse des HiveGrid-Users (jede „KWP-Box" hat eine Mail-Adresse). Welches Feld die Brücke ist, wird pro ERP-Adapter konfiguriert. 26.10.3 Sync-Richtung (mandanten-konfigurierbar): drei Modi. - Modus A (Spiegel ERP → HiveGrid): Aufgaben aus dem ERP werden in HiveGrid sichtbar, lesend. Änderungen erfolgen nur in der ERP. HiveGrid zeigt sie als „Quelle: KWP". - Modus B (Spiegel HiveGrid → ERP): in HiveGrid angelegte Aufgaben werden zur ERP übertragen. Änderungen am Ursprung (HiveGrid) übersteuern die ERP. - Modus C (bidirektional): beide Seiten lesen und schreiben. Konflikt-Auflösung wie bei M19 (System-of-Record gewinnt, Default KWP). 26.10.4 Aushebel-Schutz: keine Aufgabe kann sich gegenseitig löschen oder überschreiben. Status-Wechsel auf erledigt in einem System spiegelt sich in das andere mit Klartext-Vermerk: „Aufgabe wurde in KWP als erledigt markiert um [Zeit]." 26.10.5 Sichtbarkeit: Aufgaben mit ERP-Quelle bekommen einen visuellen Marker („KWP" als Badge), damit der Nutzer erkennt, woher sie kommen. Klick auf den Marker öffnet (sofern technisch möglich) den ERP-Eintrag. 26.10.6 Klartext-Hinweis bei Sync-Aussetzern: „KWP-Box-Synchronisation seit 12 Minuten ohne Lebenszeichen, einzelne Aufgaben fehlen eventuell. Sync-Programm prüfen." (siehe A.18 Heartbeat). 26.10.7 Abschalt-Hinweis: wird die Sync deaktiviert, behält HiveGrid die zuletzt gespiegelten Aufgaben als historische Einträge sichtbar (mit Hinweis „Historisch, Sync inaktiv"), löscht sie aber nicht.

26.11 Phase 2 / bewusst NICHT in Phase 1

26.11.1 Aufgaben-Vorlagen: wiederverwendbare Aufgaben-Definitionen mit Sub-Aufgaben. 26.11.2 Wiederkehrende Aufgaben: täglich/wöchentlich/monatlich automatisch neu erzeugt. 26.11.3 Spalten-Ansicht (Kanban) mit Drag & Drop für Status-Wechsel. 26.11.4 Abhängigkeiten zwischen Aufgaben (X blockiert Y). 26.11.5 Sub-Aufgaben mit Eltern-Kind-Hierarchie. 26.11.6 Zeit-Erfassung pro Aufgabe (Start/Stop, Stunden-Summen). 26.11.7 Erweiterte Beobachter-Logik (zum Beispiel Projektleiter wird automatisch Beobachter aller Aufgaben in seinem Projekt). 26.11.8 Eigene Aufgaben-Kommentare als separate Sub-Entität (Phase 1 nutzt den Verlaufs-Strom). 26.11.9 KI-Vorschläge für neue Aufgaben sind möglich, aber Anlage erfolgt erst nach User-Bestätigung, KI darf Aufgaben nicht direkt anlegen.

26.12 Klartext-Fehlertexte (Beispiele)

26.11.1 Leere Liste: „Keine offenen Aufgaben, schöne Sache." 26.11.2 Leere gefilterte Liste: „Mit den aktuellen Filtern keine Aufgaben gefunden. [Filter zurücksetzen]" 26.11.3 Aufgabe ohne Verantwortlichen beim Anlegen: „Wenn niemand zugewiesen ist, wirst automatisch du als Verantwortlicher eingetragen." 26.11.4 Verknüpfte Entität gelöscht: siehe 26.3.3. 26.11.5 Erinnerungs-Texte: siehe 26.6.4.

Block 4: USP-Säulen (Apps-Engine, Automatisierung, KI, KWP)

Hier liegt der Wettbewerbsvorteil von HiveGrid gegenüber HubSpot/Quiply: eine einheitliche Anbindungs-Schicht für externe Systeme, eine Automatisierungs-Engine mit KI-Erstellung per Sprache, ein KI-Layer komplett auf europäischen Modellen (DSGVO), und die saubere Anbindung an die Geerkens-Bestands-ERP KWP.

Modul 33a: Apps-Engine (einheitliche Anbindungs-Schicht)

Was es tut: Stellt eine einheitliche Anbindungs-Schnittstelle für alle externen Systeme bereit (KWP, Gmail, AirCall, Legacy-Provider, Google Calendar, PandaDoc, …). Jedes externe System wird zur „App", mit gleichem Verbindungs-Aufbau, gleichem Status-Verhalten, gleichen Fehler-Texten, gleichem Sync-Verlauf. Löst ab: Das individuelle Verdrahten externer Systeme (Zapier, Supabase-Glue, eigens gebaute Adapter). Warum es wichtig ist: Ohne diese Foundation wird jede neue Anbindung wieder Sonder-Code mit Sonder-Fehlern. Die Apps-Engine ist die Plattform-Grundlage, auf der KWP, Telefonie, Mail-Sync und Zahlungs-Anbindung sauber aufsetzen. Phase 1 ist nur die Auswahl der Apps, die Geerkens braucht (KWP, Gmail, AirCall, Legacy-Provider, Calendar). Marketplace und Drittanbieter-Apps sind ausdrücklich Phase 2.

33a.1 Was eine App ist

33a.1.1 Eine App ist die Anbindung an ein externes System (Beispiele: KWP, Gmail, AirCall, Legacy-Provider, Google Calendar, PandaDoc). 33a.1.2 Jede App hat einen Namen, eine Kategorie (z.B. ERP, Kommunikation, Kalender, Zahlung), eine Beschreibung und eine eindeutige Anbindungs-Art (z.B. Single-Sign-On per OAuth, API-Schlüssel, lokales Sync-Programm). 33a.1.3 Eine App kann pro Tenant mehrfach verbunden werden (Beispiel: drei Gmail-Postfächer in einem Betrieb, oder zwei KWP-Server an verschiedenen Standorten). Eine Verbindung trägt einen sprechenden Namen, den der Tenant-Admin selber vergibt („Geerkens Hauptbüro KWP"). 33a.1.4 Phase 1 sind ausschließlich die für Geerkens benötigten Apps freigeschaltet: KWP, Gmail, AirCall, Legacy-Provider, Google Calendar, PandaDoc. Alle weiteren Apps werden bewusst zurückgehalten, bis sie ein zahlender Kunde braucht. 33a.1.5 Eine App kann an einen Funktions-Plan gekoppelt sein (Beispiel: KWP nur in „Cloud Plus"). In tieferen Plänen wird die App im Catalog als „nicht im aktuellen Paket" markiert.

33a.2 Verbindung herstellen (Setup-Wizard)

33a.2.1 Jede App hat einen geführten Setup-Wizard mit immer derselben Reihenfolge: (1) Voraussetzungs-Check in Klartext, (2) Eingabe der Zugangsdaten oder OAuth-Anmeldung, (3) automatische Prüfung der Verbindung, (4) optionaler Initial-Sync der Bestandsdaten. 33a.2.2 Die nötigen Eingabefelder pro App werden automatisch aus der App-Definition erzeugt, der Tenant-Admin sieht nur das, was die jeweilige App tatsächlich benötigt. 33a.2.3 Vier Anbindungs-Arten werden in Phase 1 unterstützt: (a) Single-Sign-On per OAuth (Gmail, Google Calendar, Microsoft), (b) API-Schlüssel (Legacy-Provider, PandaDoc), (c) Benutzername/Passwort (Legacy-Systeme), (d) lokales Sync-Programm beim Kunden vor Ort (KWP, siehe Modul 19). 33a.2.4 Vor Abschluss prüft das System die Verbindung mit einem Probe-Aufruf. Bei Fehlschlag erscheint ein Klartext-Hinweis mit konkretem Lösungsvorschlag (z.B. „Der API-Schlüssel ist falsch oder abgelaufen. Bitte einen neuen Schlüssel im Legacy-Provider-Dashboard erstellen und hier einsetzen."). 33a.2.5 Nach erfolgreichem Setup kann der Tenant-Admin auf Wunsch direkt einen ersten Sync der Bestandsdaten anstoßen, mit Klartext-Vorschau („1.247 Kontakte und 384 Aufträge aus KWP übernehmen?").

33a.3 Verbindungs-Status (sichtbar überall)

33a.3.1 Jede Verbindung hat zu jedem Zeitpunkt genau einen von fünf Zuständen: wartet auf Setup, aktiv, eingeschränkt, defekt, getrennt. 33a.3.2 Der Zustand wird mit einer farbigen Anzeige dargestellt (grün, gelb, rot, grau) und immer mit einem Klartext-Hinweis begleitet, nie ohne Erklärung. 33a.3.3 Beispiele für die Klartexte: - aktiv: „Verbindung zu KWP läuft. Letzter erfolgreicher Sync vor 4 Minuten." - eingeschränkt: „KWP-Verbindung verlor Token-Aktualität. Bitte in den Einstellungen den Verbindungs-Token erneuern." - defekt: „Verbindung zu KWP nicht erreichbar. Mögliche Ursachen: Sync-Programm beim Kunden vor Ort nicht gestartet, Netzwerk unterbrochen, Server-Update läuft." 33a.3.4 Der Status wird im Hintergrund automatisch geprüft: bei aktiver Verbindung alle 5 Minuten, bei eingeschränktem Status engmaschiger (1 Minute), bei defekter Verbindung weniger häufig (15 Minuten, um keine zusätzliche Last zu erzeugen). 33a.3.5 Bleibt eine Verbindung länger als 30 Minuten eingeschränkt, geht eine Email- und In-App-Benachrichtigung an den Tenant-Admin. Bei sofortigem Ausfall (defekt) wird sofort benachrichtigt. Sobald sich die Verbindung erholt, kommt die Klartext-Bestätigung („KWP-Verbindung ist wieder aktiv.").

33a.4 Sync-Verhalten

33a.4.1 Vier Sync-Arten werden unterstützt: (a) regelmäßiges Abholen (z.B. Gmail alle 5 Minuten, KWP alle 30 Sekunden), (b) Daten aktiv ans externe System schicken (z.B. neuer Auftrag wird in KWP angelegt), (c) das externe System ruft uns an („Webhook"), (d) der Tenant-Admin stößt manuell einen Sync an. 33a.4.2 Pro Sync-Vorgang entsteht ein Eintrag im Sync-Verlauf der App, immer mit Klartext-Zusammenfassung („Sync mit KWP, 14 Aufträge gepullt, 2 fehlgeschlagen wegen veraltetem Schema"). 33a.4.3 Pro Vorgang wird detailliert protokolliert, was passiert ist (welche Datensätze angelegt, aktualisiert oder übersprungen wurden, welche fehlgeschlagen sind und warum). Der Tenant-Admin kann diesen Verlauf nach Datum, Status und Operation filtern. 33a.4.4 Alle Aktionen sind durch einen Schutz vor doppelter Ausführung abgesichert, selbst wenn ein Sync-Vorgang doppelt ausgelöst wird (durch Netzwerk-Wackler oder manuellen Re-Sync), wird kein Datensatz doppelt geschrieben. 33a.4.5 Pro App läuft maximal ein regelmäßiger Sync-Vorgang gleichzeitig, keine sich überholenden Sync-Läufe.

33a.5 Schutz vor zu vielen oder unerwarteten Daten

33a.5.1 Webhook-Sturm-Schutz: Externe Systeme können uns nur eine konfigurierbare Anzahl Ereignisse pro Stunde melden. Alles darüber wird verworfen mit Klartext-Hinweis an den Tenant-Admin. 33a.5.2 Anomalie-Erkennung: Wenn das Sync-Volumen plötzlich das Zehnfache des Normalen erreicht, wird der Sync automatisch pausiert und der Tenant-Admin informiert. Damit wird eine versehentliche Spam-Welle nicht weiterverarbeitet.

33a.6 Schema-Drift-Schutz

33a.6.1 Wenn ein externes System sein Datenmodell ändert (Felder umbenannt, neue Pflichtfelder, gelöschte Spalten), erkennt der Sync das automatisch und pausiert die Verbindung, Sicherheit geht vor Verfügbarkeit. 33a.6.2 Bei erkannter Änderung wird zuerst der Plattform-Anbieter (wir) benachrichtigt, nicht der Tenant. Der Tenant sieht nur den Klartext: „Wir wurden informiert und beheben das." 33a.6.3 Erst nach Anpassung der Anbindungs-Logik durch uns wird die Verbindung wieder freigegeben, mit Audit-Eintrag.

33a.7 Verwaltungs-Bereich für den Tenant-Admin

33a.7.1 Es gibt einen zentralen Bereich „Integrationen", in dem alle verfügbaren Apps gruppiert nach Kategorie zu sehen sind, mit Filterung und Suche. 33a.7.2 Pro App sieht der Tenant-Admin: Beschreibung, alle bestehenden Verbindungen, deren Status, letzten Sync-Zeitpunkt und Zugriff auf den Sync-Verlauf. 33a.7.3 Pro Verbindung gibt es die Funktionen: manuelles erneutes Synchronisieren, Zugangsdaten aktualisieren, Verbindung erneut aufbauen (nach Token-Ablauf), Verbindung trennen. 33a.7.4 Verbindungen trennen läuft über eine Mehrfach-Bestätigung mit Klartext-Warnung („Beim Trennen werden alle Sync-Jobs gestoppt. Eingehende Ereignisse werden nicht mehr verarbeitet."). Eine getrennte Verbindung bleibt im System sichtbar (Audit-Trail-Pflicht), wird aber nicht weiter genutzt.

33a.8 Berechtigungen

33a.8.1 Sechs feingranulare Berechtigungen: Verbindungen sehen, neu anlegen, trennen, manuell synchronisieren, Logs einsehen, voll administrieren. 33a.8.2 Standard-Vergabe: Geschäftsführer und Tenant-Admin haben alles, Vertriebsleiter sehen nur, Büro/Backoffice darf manuell syncen.

33a.9 Phase 2 / bewusst NICHT in Phase 1

33a.9.1 Drittanbieter-Marketplace: Externe Entwickler bauen eigene Apps für HiveGrid, Tenants installieren aus einem Katalog. Erfordert Sandboxing und Review-Prozess. Erst nach Geerkens-Launch. 33a.9.2 Template-Marketplace: Vorgefertigte Pipelines, Forms, Automatisierungen, Dashboard-Layouts zum Kaufen oder Teilen. Auch Phase 2. 33a.9.3 Verschlüsselung pro Tenant mit eigenem Schlüssel-Verwaltungs-System: Phase-2-Verfeinerung. Phase 1 verschlüsselt mit Plattform-Schlüssel, was DSGVO-konform ist.

33a.10 Klartext-Fehlertexte (Beispiele)

33a.10.1 OAuth-Token abgelaufen: „Die Anmeldung bei {App} ist abgelaufen. Bitte erneut anmelden, dann läuft der Sync wieder." 33a.10.2 API-Schlüssel ungültig: „Der API-Schlüssel wurde nicht akzeptiert. Bitte einen neuen Schlüssel im {App}-Dashboard erstellen und hier einsetzen." 33a.10.3 Anbieter erreichbar, aber Antwort fehlerhaft: „{App} antwortet aktuell nicht wie erwartet. Wir haben den Sync pausiert und prüfen die Ursache." 33a.10.4 Sync-Volumen-Anomalie: „Es kommen ungewöhnlich viele Daten herein. Wir haben den Sync zur Sicherheit pausiert. Bitte prüfen, ob das beabsichtigt ist."

Modul 17: Automation Engine

Was es tut: Ermöglicht dem Tenant, „Wenn X passiert, dann tue Y"-Regeln zu bauen, visuell mit Knoten und Verbindungen, oder per Sprache an die KI („Wenn jemand das Kontaktformular ausfüllt und das Volumen über 10.000 Euro ist, schicke mir und dem Vertriebsleiter eine Push-Benachrichtigung"). Löst ab: Zapier, n8n, Supabase-Glue, „der Sohn schraubt am Wochenende was zusammen"-Lösungen. Warum es wichtig ist: Das ist die zentrale USP-Säule. Ohne mächtige, aber selbst wartbare Automatisierungen bleibt HiveGrid eine Datenbank. Mit ihnen wird HiveGrid zum Betriebssystem des Handwerksbetriebs. Die Anti-Agentur-Positionierung lebt davon, dass Noah selbst Automatisierungen anpassen kann, ohne uns oder eine Agentur zu rufen.

17.1 Was eine Automatisierung ist

17.1.1 Eine Automatisierung trägt einen Namen, eine Beschreibung und besteht aus einer beliebigen Zusammenstellung von Bausteinen: ein oder mehrere Auslöser (was startet die Automatisierung), beliebig viele Bedingungen (Wenn-Filter), beliebig viele Aktionen (was passiert), und Steuerungs-Bausteine (Wartezeit, Verzweigung, parallele Pfade, Zusammenführung). 17.1.2 Eine Automatisierung ist entweder aktiv oder inaktiv. Inaktive Automatisierungen lösen nicht aus, bleiben aber gespeichert. 17.1.3 Pro Automatisierung wird festgehalten: wer sie angelegt hat, wann sie zuletzt ausgeführt wurde, wie oft sie in den letzten 30 Tagen ausgelöst hat, ob sie manuell, aus einer Vorlage oder per KI-Sprachbefehl entstanden ist. 17.1.4 Automatisierungen können archiviert werden (statt gelöscht), um die Historie nicht zu zerstören.

17.2 Welche Auslöser (Phase 1)

Auslöser entstehen aus den verschiedenen Modulen, der Tenant kombiniert das, was er fachlich braucht. Phase-1-Liste:

17.2.1 CRM: neuer Kontakt angelegt, Kontakt geändert, Kontakt mit Schlagwort versehen. 17.2.2 Leads: neuer Lead empfangen (mit Filter auf Quelle), Lead-Status geändert, Lead zugewiesen. 17.2.3 Sales-Pipeline (Deals): Deal angelegt, Deal-Stufe geändert, Deal gewonnen, Deal verloren, Deal länger als X Tage in einer Stufe stecken geblieben, Zuständiger geändert, Volumen geändert. Jeder Auslöser kann nach Pipeline und Stufe gefiltert werden. 17.2.4 Projekt-/Auftragspipeline: Projekt angelegt, Stufe geändert, abgeschlossen, abgebrochen, in Stufe stecken geblieben, Mitglied hinzugefügt/entfernt, Abnahme abgeschlossen (mit Filter „komplett" / „mit Mängeln"), Termin angelegt/geändert/abgesagt. 17.2.5 Forms: Formular abgeschickt (pro Formular einzeln auswählbar). 17.2.6 Booking: Termin gebucht, abgesagt, beim Termin erschienen. 17.2.7 Email: Mail im Posteingang empfangen (pro Postfach), Betreff entspricht einem Muster. 17.2.8 Telefonie: eingehender Anruf abgeschlossen, ausgehender Anruf abgeschlossen, Anruf verpasst. 17.2.9 Aufgaben: Aufgabe angelegt, zugewiesen, erledigt, Frist nähert sich, überfällig. 17.2.10 Zeitbasiert: nach Zeitplan (z.B. „jeden Montag um 8 Uhr"), nach einer Wartezeit als Folge-Schritt. 17.2.11 KWP: neuer Auftrag aus KWP eingespielt, Datenmodell-Änderung in KWP erkannt. 17.2.12 Apps-Engine: Verbindungs-Status einer App geändert, Sync einer App fehlgeschlagen. 17.2.13 HR: Urlaub genehmigt, Krankmeldung eingegangen. 17.2.14 Kunden-Portal: Kunde hat eine Datei hochgeladen, Kunde hat geantwortet.

17.3 Welche Aktionen (Phase 1)

17.3.1 CRM: Kontakt aktualisieren, Schlagwort hinzufügen/entfernen, Kontakt einem Mitarbeiter zuweisen. 17.3.2 Leads: Lead zuweisen, Status setzen, in Kontakt umwandeln. 17.3.3 Sales: Deal anlegen (mit Ziel-Pipeline und Start-Stufe), Stufe ändern, Volumen ändern, zuweisen, Schlagwort hinzufügen, in andere Pipeline verschieben. 17.3.4 Projekte: Projekt anlegen (mit Ziel-Pipeline und Start-Stufe), Projekt aus gewonnenem Deal anlegen mit konfigurierbarer Standard-Zuordnung pro Sales-Pipeline (Beispiel: Sales-Pipeline „Anlagen-Verkauf" → Projekt-Pipeline „Anlagen-Installation"), Stufe ändern, Mitglied hinzufügen, Aufgabe anlegen, Termin anlegen, Abnahme starten, in andere Pipeline verschieben. 17.3.5 Kommunikation: Email senden (mit Vorlage und dynamischen Platzhaltern), Chat-Nachricht in einem Channel posten, Push-Benachrichtigung senden, In-App-Benachrichtigung senden. 17.3.6 Aufgaben: Aufgabe anlegen, einem Mitarbeiter zuweisen. 17.3.7 KWP: Auftrag in KWP anlegen oder aktualisieren. 17.3.8 Externe Aufrufe: HTTP-Anfrage an beliebige URL (GET, POST, PUT, DELETE), signierter Webhook an externes System. 17.3.9 Steuerung: Wartezeit, Verzweigung („wenn X dann hier lang, sonst dort lang"), parallele Pfade, Zusammenführung paralleler Pfade. Schleifen sind in Phase 1 ausdrücklich nicht erlaubt (zu hohes Risiko von Endlos-Schleifen und Webhook-Stürmen). 17.3.10 KI-Aktionen: Text generieren, zusammenfassen, klassifizieren (alle laufen über den KI-Layer aus Modul 18). 17.3.11 Kalender: Termin anlegen, Termin aktualisieren. 17.3.12 Dateien: Datei aus URL erzeugen.

17.4 Welche Bedingungen

17.4.1 Feld-Vergleich: gleich, enthält, größer als, kleiner als. 17.4.2 Schlagwort gesetzt / nicht gesetzt. 17.4.3 Tageszeit / Wochentag. 17.4.4 Mitarbeiter ist in einer bestimmten Gruppe. 17.4.5 Frei programmierbarer Ausdruck (z.B. JavaScript) ist bewusst Phase 2: Sicherheits-Risiko, kommt erst mit Sandbox.

17.5 Visueller Editor

17.5.1 Eine Automatisierung wird in einem visuellen Editor mit Knoten und Verbindungen aufgebaut. Knoten sind Auslöser, Bedingungen, Aktionen oder Steuerungs-Bausteine. Verbindungen zeigen den Fluss. 17.5.2 Knoten werden aus einem seitlichen Katalog per Klick oder Ziehen hinzugefügt. Der Katalog ist nach Modul gefiltert. 17.5.3 Pro Knoten gibt es einen Konfigurations-Bereich, der die nötigen Einstellungen abfragt (z.B. „welche Pipeline?", „welcher Empfänger?", „welche Vorlage?"). 17.5.4 Im Knoten-Label steht immer der fachliche Klartext: „Wenn Deal in Pipeline ‚Anlagen-Verkauf' → Stufe ‚Verhandlung'", „Wenn Volumen > 10.000 Euro", „Push an Noah G. + Vertriebsleiter", „Warte 24 Stunden". 17.5.5 Der Editor hat: Zoom, Verschieben, Mini-Map für große Flüsse, Rückgängig/Wiederholen, automatische Anordnung, Knoten duplizieren, Knoten löschen. 17.5.6 Vor dem Speichern prüft der Editor automatisch auf Probleme und zeigt Klartext-Hinweise: - „Knoten ‚Email senden' ist nicht verbunden, wird nie ausgeführt" - „Diese Verbindung würde eine Schleife bilden, bitte anders verkabeln" - „Bei ‚Email senden' fehlt der Empfänger" 17.5.7 Eine gespeicherte Automatisierung muss explizit aktiviert werden, bevor sie auslöst, versehentliches Live-Schalten ist nicht möglich.

17.6 KI-Erstellung per Sprache

17.6.1 Der Tenant gibt einen Wunsch in Klartext ein (oder spricht ihn ein über die Sprach-zu-Text-Funktion aus Modul 18). Beispiel: „Wenn jemand das Kontaktformular ausfüllt und das Volumen über 10.000 Euro ist, schicke mir und dem Vertriebsleiter eine Push-Benachrichtigung und lege den Lead in der Premium-Pipeline an." 17.6.2 Die KI baut daraus einen Vorschlag und zeigt ihn (a) als fertig zusammengeklickte Automatisierung im visuellen Editor und (b) als Klartext-Beschreibung darunter. 17.6.3 Wenn die KI etwas nicht eindeutig zuordnen kann, fragt sie zurück, statt zu raten: „Du meinst Klaus Müller (Vertriebsleiter Süd) oder Klaus Schmidt (Bauleiter Nord)?" 17.6.4 Die KI prüft vorher, ob alle referenzierten Pipelines, Stufen, Formulare, Mitarbeiter, Vorlagen tatsächlich existieren, sie erfindet keine Felder, keine Empfänger, keine Stufen. 17.6.5 Bei Risiko-Konstellationen ergänzt die KI einen Klartext-Warnhinweis im Vorschlag, z.B. „Achtung: ‚Volumen über 10.000' kann auch bei Wartungsverträgen mit hohem Vertragswert greifen, willst du nur die Anlagen-Verkauf-Pipeline einschränken?" 17.6.6 Die KI führt niemals eine Automatisierung selber aus oder aktiviert sie. Der Tenant muss aktiv bestätigen. 17.6.7 Bestehende Automatisierungen können per Sprache bearbeitet werden („Füge eine Wartezeit von 1 Tag zwischen der Email und der Push-Benachrichtigung ein"). Die KI zeigt die Änderung als Vergleich („vorher / nachher") an.

17.7 Vorschau, Test-Lauf und Rückgängig-Machen

17.7.1 Vor dem Aktivieren kann eine Automatisierung als Test-Lauf simuliert werden, ohne echte Wirkung nach außen. Es wird Schritt für Schritt in Klartext gezeigt, was passieren würde („Email würde versandt an: noah@geerkens.de mit Betreff ‚Premium-Lead'"). 17.7.2 Wenn eine Automatisierung beim ersten echten Lauf mehr als 100 Datensätze gleichzeitig betreffen würde (Schwellenwert tenant-konfigurierbar), ist eine Klartext-Vorschau Pflicht: „Diese Automatisierung würde jetzt 1.400 Personen treffen. Hier die ersten 5: …", erst nach Bestätigung wird ausgeführt. 17.7.3 Jede Ausführung kann innerhalb von 24 Stunden rückgängig gemacht werden. Der Tenant sieht im Ausführungs-Log die verbleibende Zeit („Du hast noch 23h 12min, um diese Ausführung zurückzunehmen"). 17.7.4 Reversibel sind: angelegte Datensätze (werden gelöscht), Status-Änderungen (werden zurückgesetzt), Schlagwort-Änderungen (werden rückgängig gemacht). Email-Versand ist nicht zurückziehbar, aber die Empfänger-Liste wird angezeigt, damit der Tenant die Lage einschätzen kann. 17.7.5 Rückgängig-Machen erfordert Mehrfach-Bestätigung und erzeugt einen Audit-Eintrag.

17.8 Schutz-Mechanismen (Webhook-Stürme, Schleifen, halbe Ausführungen)

Diese Schutz-Mechanismen sind die Sicherheits-Garantie für Noah, drei reale Risiken aus dem Pre-mortem, je mit verbindlicher Antwort:

17.8.1 Schutz vor Webhook-Stürmen (Risiko: Spam-Welle füttert über Kontaktformular 2.000 Fake-Leads in 5 Minuten, würden ohne Schutz 2.000 Aufträge in KWP, 2.000 Push-Nachrichten erzeugen): - Pro Auslöser ein Hard-Limit (Standard 1.000 Auslösungen pro Stunde, vom Tenant-Admin nach oben oder unten anpassbar). Alles darüber wird verworfen, mit Klartext-Hinweis. - Anomalie-Erkennung: Wenn die Auslöse-Rate plötzlich zehnmal so hoch ist wie der typische Verlauf der letzten Wochen, wird die Automatisierung automatisch pausiert: „Die Automatisierung ‚Lead-Begrüßung' wurde 2.000-mal in 5 Minuten ausgelöst, typisch sind 5-10 pro Tag. Wir haben sie pausiert. Bitte prüfen." - Beide Schutzschichten sind aktiv (Hard-Limit als Fangnetz, Anomalie-Erkennung als smarter Vor-Schutz).

17.8.2 Schutz vor Endlos-Schleifen (Risiko: Automatisierung A setzt ein Schlagwort, B reagiert auf das Schlagwort und ändert die Stufe, A reagiert auf die Stufen-Änderung, Endlos-Schleife): - Pro Datensatz und Minute maximal 5 automatische Auslösungen. Danach Abbruch mit Klartext-Stopp: „Automatisierung A löst B aus, B löst A aus, Schleife erkannt, beide pausiert." - Schon beim Speichern prüft das System den Abhängigkeits-Graph und warnt vor potenziellen Schleifen, bevor sie aktiv werden können.

17.8.3 Schutz bei halber Ausführung (Risiko: Eine Automatisierung mit 5 Schritten, Schritt 4 ist KWP-Push und scheitert. Schritte 1-3 sind durch, 4-5 nicht. Ein einfacher Retry würde 1-3 doppelt ausführen): - Jede Aktion hat einen Schutz vor doppelter Ausführung: bei Wiederholung wird geprüft „schon erledigt?" und ggf. übersprungen. - Wiederholung beginnt am fehlgeschlagenen Schritt, nicht von vorne („Wiederaufnahme ab Schritt 4"). - Der Klartext-Status zeigt: „Automatisierung X war zu 60% durch (3/5 Schritte erfolgreich). Schritt 4 (KWP-Sync) fehlgeschlagen. Auto-Wiederholung in 5 Minuten. [Manuell wiederholen] [Ab Schritt 4 weitermachen] [Abbrechen]" - Automatische Wiederholung mit zunehmenden Wartezeiten: 1 Min, 5 Min, 15 Min, 1 Std, 6 Std, 24 Std. Nach 6 Versuchen wird der Tenant-Admin per Klartext-Email informiert.

17.9 Klartext-Logs (jede Ausführung nachvollziehbar)

17.9.1 Pro Automatisierung gibt es eine Liste aller Ausführungen mit Datum, Status (erfolgreich / teils erfolgreich / fehlgeschlagen / abgebrochen), Dauer und Klartext-Zusammenfassung. 17.9.2 Pro Ausführung kann der Tenant in eine Detail-Ansicht klicken und sieht Schritt für Schritt: was passiert ist, wie lange es gedauert hat, welche Eingaben/Ausgaben es gab, ob ein Fehler aufgetreten ist und wenn ja in Klartext. 17.9.3 Beispiel-Texte: - Erfolgreich: „Lead-Begrüßung wurde ausgeführt. Email an max.mueller@example.com gesendet. Dauer: 0,8 Sekunden." - Teil-Erfolg: „Won-Handoff: Projekt erstellt ✓, Push gesendet ✓, KWP-Sync fehlgeschlagen ✗, Verbindung zu KWP nicht erreichbar. Auto-Wiederholung in 5 Minuten." - Fehler: „Fehler beim Schritt ‚Email senden': Empfänger-Email nicht zustellbar. [Empfänger prüfen]" - Übersprungen: „Schritt ‚Email senden' wurde übersprungen, weil ‚Bedingung Volumen > 10.000' nicht erfüllt war (tatsächlich: 2.500)." 17.9.4 Aus dem Log heraus kann manuell eine Ausführung wiederholt oder eine Wirkung rückgängig gemacht werden (innerhalb des 24-Stunden-Fensters).

17.10 Vorlagen (für schnellen Einstieg und als Vertriebszweig) [N12, 09.05.2026]

Erweiterung gem. Anmerkung Noah, 09.05.2026: Vorlagen sind nicht nur Onboarding-Beschleuniger, sondern strategischer Vertriebszweig. Ziel: User mit hochwertigen Vorlagen so produktiv machen, dass sie sich an die Plattform binden, und über einen kostenpflichtigen Marketplace zusätzliche Umsätze generieren. Eine kommerzielle Ausrichtung wird Architektur-seitig in Phase 1 vorbereitet (Eigentümer-Feld pro Vorlage, Bezahl-Schnittstelle als Hülle), die Marketplace-Frontend-Aktivierung selbst bleibt Phase 2 (siehe Vision V.3.2.18 Anti-Liste).

17.10.1 Plattform-Vorlagen (von uns mitgeliefert, branchenspezifisch). Für SHK-Betriebe vorgesehen z.B.: - „Lead-Begrüßung" (neuer Lead → automatische Email mit Wartungstermin-Vorschlag) - „Won-Handoff zur Installation" (Deal gewonnen → Projekt automatisch anlegen + Push an Projektleiter) - „Termin-Erinnerung an Endkunden" (1 Woche vor Termin automatische Erinnerung) - „Stuck-Deal-Eskalation" (Deal länger als 14 Tage in „Angebot" → Push an Vertriebsleiter) - „Anrufe-Rückruf" (verpasster Anruf → Aufgabe für Vertriebler mit 24-Stunden-Frist) - „Acceptance-Komplett-Workflow" (Abnahme abgeschlossen → Email + Kunden-Portal-Update + KWP-Rechnungs-Auslöser) - „Mängel-Aufgaben-Generator" (Abnahme mit Mängeln → für jeden Mangel eine Aufgabe mit 7-Tage-Frist) 17.10.2 Eigene Vorlagen pro Mandant: Mandanten können aus jeder bestehenden Automatisierung eine Vorlage erstellen, mit Titel, Beschreibung, Vorschau-Bild und Pflicht-Variablen (Eingabe-Felder, die der Nutzer beim Anwenden ausfüllt). 17.10.3 Vorlagen-Eigentümer und Sichtbarkeit (Phase-1-Vorbereitung für Marketplace): - jede Vorlage hat einen Eigentümer (HiveGrid-Plattform / Mandant / einzelner Nutzer). - Sichtbarkeit pro Vorlage: nur intern (eigener Mandant) / öffentlich-mit-Mandanten-Zustimmung (Marketplace, Phase 2) / öffentlich-kostenfrei / öffentlich-kostenpflichtig. - Mandanten-eigene Vorlagen sind in Phase 1 nur intern sichtbar; Marketplace-Sichtbarkeit wird in Phase 2 aktiviert. 17.10.4 Kommerzielle Vorlagen-Anbieterschaft (Phase 1 vorbereitet, Phase 2 aktiviert): - Plattform-Vorlagen können kostenpflichtig sein (Einmalzahlung pro Mandant; alternativ Mini-Abo). Bezahlung läuft über das Subscription-Modul (M28) und Legacy-Provider. - Mandanten-Vorlagen, die im Marketplace verkauft werden, generieren Umsatz an den anbietenden Mandanten (Revenue-Share). Konkrete Provision wird mit dem Pricing-Modell festgelegt (geparkt, siehe H.1.1). - Auswertung pro Vorlage: Anzahl Anwendungen, Anzahl bezahlter Käufe, häufige Anpassungen durch Anwender. 17.10.5 Service-Einsätze und Wartung sind keine Beispiele (siehe N9): „Wartungstermin-Reminder" wurde durch „Termin-Erinnerung an Endkunden" ersetzt, die für jede Termin-Art (Vor-Ort-Termin, Abnahme, Service) gilt. Ein dediziertes Service-Modul kommt erst in Phase 2.

17.11 Festhängende Stufen automatisch eskalieren

17.11.1 Ein eingebauter Tageslauf prüft alle Pipelines auf Datensätze, die länger als die pro Stufe konfigurierte Schwelle in einer Stufe stecken bleiben. 17.11.2 Bei Erreichen wird ein Auslöser-Ereignis erzeugt („Deal D-2026-0042 hängt seit 18 Tagen in ‚Verhandlung'"). Auf dieses Ereignis kann der Tenant eigene Automatisierungen hängen. 17.11.3 Die Schwellenwerte pro Stufe sind vom Tenant-Admin konfigurierbar.

17.12 Mengen-Begrenzung pro Plan

17.12.1 Pro Tenant wird die Anzahl ausgeführter Automatisierungen pro Monat gezählt und im Verbrauchs-Bereich des Tenant-Admins angezeigt. 17.12.2 Bei 80% des Plan-Limits Klartext-Warnung. Bei Überschreitung werden weitere Ausführungen in eine Warteschlange gelegt mit Klartext-Hinweis: „Trigger-Volumen für diesen Monat überschritten. Automatisierungen laufen ab nächstem Monat wieder. Erweiterung im Plan möglich." 17.12.3 Konkrete Mengen pro Plan werden mit der Pricing-Festlegung definiert (parkiert).

17.13 Berechtigungen

17.13.1 Acht feingranulare Berechtigungen: Lesen, Test-Lauf, Schreiben, Aktivieren/Deaktivieren, Löschen, Wirkungen rückgängig machen, KI-Erstellung nutzen, voll administrieren. 17.13.2 Standard-Vergabe: Geschäftsführer voll, Vertriebsleiter darf bauen + aktivieren + rückgängig machen, Projektleiter darf bauen aber nicht aktivieren (Freigabe durch Geschäftsführer), Vertriebler/Büro nur Lesen, Marketing darf bauen + aktivieren. 17.13.3 Klartext-Fehler bei fehlender Berechtigung: - „Du kannst Automatisierungen bauen, aber das Aktivieren erfordert Freigabe durch einen Admin. [Freigabe anfordern]" - „Diese Ausführung kann nicht mehr zurückgenommen werden, das 24-Stunden-Fenster ist abgelaufen." - „Die KI-gestützte Erstellung ist im Cloud-Plus-Plan verfügbar."

17.14 Phase 2 / bewusst NICHT in Phase 1

17.14.1 Schleifen-Konstrukte in Automatisierungen, zu hohes Risiko von Endlos-Ausführungen, kommt mit Sandbox in Phase 2. 17.14.2 Frei programmierbarer Ausdruck als Bedingung (eigener JavaScript-Code), Sicherheits-Risiko, Phase 2. 17.14.3 Versionierung von Automatisierungen mit Vergleich und Rollback älterer Stände, Phase 2. 17.14.4 WhatsApp als Auslöser/Aktion, komplette WhatsApp-Anbindung erst Phase 2.

17.15 Klartext-Fehlertexte (Beispiele)

17.15.1 Ungültige Empfänger-Email: „Die Email an ‚max.mueller@example.invalid' konnte nicht zugestellt werden, die Adresse existiert nicht. Bitte den Kontakt aktualisieren." 17.15.2 KWP-Push fehlgeschlagen: „Auftrag konnte gerade nicht in KWP angelegt werden, Verbindung zu KWP ist defekt. Wir versuchen es in 5 Minuten automatisch erneut." 17.15.3 Schleife verhindert: „Diese Verbindung würde eine Schleife bilden, bitte anders verkabeln. [Visualisierung der erkannten Kette]" 17.15.4 Anomalie-Pause: „Diese Automatisierung wurde ungewöhnlich oft ausgelöst (10× über dem Normalwert) und sicherheitshalber pausiert. Bitte prüfen, ob das gewollt ist. [Wieder aktivieren] [Anpassen]"

Modul 18: KI-Layer

Was es tut: Stellt eine zentrale Stelle bereit, durch die alle KI-Funktionen der Plattform laufen, Lead-Zusammenfassungen, Programm-Hilfe-Chat, KI-Erstellung von Automatisierungen, Sprach-Transkription, Klassifizierung, Stuck-Deal-Vorschläge. Löst ab: Einzelne KI-Stümpfe in jedem Modul + die übliche Direkt-Anbindung an OpenAI/Anthropic (DSGVO-Sprengstoff). Warum es wichtig ist: USP-Säule mit knallhartem Verkaufs-Argument: HiveGrid nutzt ausschließlich europäische KI-Modelle. Keine Daten verlassen die EU, niemals. Damit fällt der DSGVO-Verkaufsblocker weg, der bei vielen Mittelständlern bisher KI-Projekte gestoppt hat. Außerdem: alle KI-Funktionen laufen über genau eine zentrale Stelle, so dass Kosten kontrollierbar sind und Ausfälle eines KI-Anbieters nicht die ganze Plattform lahmlegen.

18.1 Welche KI-Funktionen (Phase 1)

18.1.1 KI-Erstellung von Automatisierungen (siehe Modul 17.6), Sprach- oder Text-Eingabe wird in eine fertige Automatisierung verwandelt, mit Vorschau und Rückfrage bei Mehrdeutigkeit. 18.1.2 Lead-Zusammenfassung vor Terminen: vor jedem Sales-Termin sieht der Vertriebler eine knappe KI-Zusammenfassung: „Lead hat sich für Wärmepumpe interessiert, vorheriger Anruf am Mittwoch dauerte 8 Min, dabei wurde ein Termin heute 10:00 vereinbart. Volumen geschätzt 25.000 Euro.", basiert auf der Aktivitäts-Historie, Custom-Feldern und verlinkten Formular-Einsendungen. 18.1.3 Programm-Hilfe-Chat: In-App-Chat, in dem User Fragen zur Bedienung stellen können („Wie lege ich eine neue Pipeline an?"). KI antwortet in Klartext mit Direkt-Link zur passenden Funktion. Antwort basiert auf den Help-Center-Artikeln (Modul 38). 18.1.4 Klartext-Diagnostik-Vorschläge als Fallback: wenn ein Fehler auftritt, für den noch keine fest formulierte Erklärung im System hinterlegt ist, kann die KI einen Vorschlag liefern (klar als „KI-Vorschlag" markiert mit Hinweis, im Zweifel den Plattform-Anbieter zu kontaktieren). Der Standardweg ist immer der fest formulierte Klartext: KI ist nur Fallback. 18.1.5 Stuck-Deal-Vorschläge: wöchentlich generiert die KI Vorschläge für festhängende Deals oder Projekte: „Deal D-2026-0042 ist seit 18 Tagen in Verhandlung. Vorschlag: Follow-Up-Anruf oder Email mit Angebots-Anpassung." 18.1.6 Sprach-Transkription für Abnahme-Voice-Notes (Modul 4), Anruf-Notizen, Diktate in Markdown-Editoren. 18.1.7 Email-Klassifizierung (minimal): eingehende Mails werden automatisch grob kategorisiert (Lead, Kunden-Frage, Rechnung, Spam, Newsletter, Sonstiges). Beeinflusst die automatische Zuordnung im Posteingang und kann als Auslöser für Automatisierungen genutzt werden.

18.2 Welche Modelle (alle EU)

18.2.1 Phase 1 ausschließlich europäische Anbieter: DSGVO-Pflicht, keine Ausnahme: - Mistral Cloud (Frankreich), Hauptmodell für Chat und KI-Erstellung von Automatisierungen. - Scaleway Generative API (Frankreich), alternatives Modell und Embeddings (für Suche). - AlephAlpha Luminous (Deutschland), drittes Modell als Reserve. - Whisper auf eigener Scaleway-Infrastruktur: Sprach-zu-Text, läuft auf europäischer Hardware, nicht über externe Anbieter. 18.2.2 Ausgeschlossen sind in Phase 1: OpenAI, Anthropic, Google Gemini, auch wenn diese Modelle qualitativ teils stärker sind. Das ist eine bewusste DSGVO-Hard-Constraint. 18.2.3 Pro Anwendungsfall ist ein Standard-Modell hinterlegt (z.B. Mistral Large für die KI-Erstellung von Automatisierungen, Mistral Small für Lead-Zusammenfassungen). Der Tenant-Admin kann pro Anwendungsfall ein anderes Modell wählen. 18.2.4 In den Tenant-Einstellungen steht zentral der Klartext: „KI-Funktionen werden ausschließlich von EU-Providern (Mistral, Scaleway, AlephAlpha) bedient. Keine Daten verlassen die EU." 18.2.5 Eigene Anbieter-Schlüssel (Tenant bringt z.B. eigenen Mistral-Account mit) ist Phase 2.

18.3 KI-Suche in eigenen Daten (für Programm-Hilfe und Lead-Zusammenfassung)

18.3.1 Bei wichtigen Datensätzen (Kontakte, Deals, Projekte, Notizen, Formular-Einsendungen, Hilfe-Artikel) wird automatisch eine semantische Repräsentation berechnet, sobald der Datensatz angelegt oder geändert wird. Damit kann die KI später inhaltlich ähnliche Datensätze finden, nicht nur per Stichwort. 18.3.2 Anwendungsfälle: globale Suche (Modul 24) findet auch sinngemäß Passendes, Programm-Hilfe-Chat findet die richtigen Artikel auch bei umgangssprachlicher Frage, Lead-Zusammenfassung findet ähnliche Deals zur Einordnung. 18.3.3 Sicherheits-Pflicht: Vor jeder Suche werden die Berechtigungen des fragenden Users geprüft, die KI darf einem Vertriebler keine Inhalte zeigen, die er ohne KI auch nicht sehen dürfte. 18.3.4 Bei Anbieter-Ausfall fällt die semantische Suche auf normale Volltext-Suche zurück, mit Klartext-Hinweis: „Semantische Suche ist gerade nicht verfügbar, Standard-Volltext-Suche aktiv."

18.4 Sprach-zu-Text (Whisper-EU)

18.4.1 Der User kann in der Mobile-App und im Web sprechen und bekommt das Gesprochene als Text geschrieben. Anwendungsfälle: Abnahme-Voice-Notes auf der Baustelle, Anruf-Notizen-Diktat, Diktat in beliebige Notiz-/Text-Felder. 18.4.2 Erkennt automatisch Deutsch (primär) und Englisch (sekundär). 18.4.3 Der User kann den erzeugten Text vor dem Speichern korrigieren. 18.4.4 Bei Fehlschlag Klartext: „Audio konnte nicht transkribiert werden, bitte erneut aufnehmen oder manuell tippen."

18.5 Sicherheit gegen Prompt-Injection

18.5.1 Externe Daten (Formular-Einsendungen, eingehende Mails, Anruf-Transkripte) werden vor jedem KI-Aufruf bereinigt: Steuer-Marker, die die KI in eine andere Richtung lenken könnten, werden neutralisiert. 18.5.2 Im Prompt-Aufbau gibt es eine strikte Trennung zwischen System-Anweisungen, Nutzer-Daten („nicht als Anweisungen interpretieren") und der eigentlichen Frage. 18.5.3 Aktions-Grenze: Die KI darf aus externen Daten oder semantischer Suche niemals schreibende Aktionen ableiten ohne explizite User-Bestätigung. Auch wenn in einer eingehenden Email steht „Bitte sofort 1.000 Euro überweisen", darf die KI nichts auslösen. 18.5.4 Pro KI-Funktion wird kontinuierlich eine automatische Sicherheits-Prüfung mitgefahren, bei jedem Code-Update werden Standard-Angriffsmuster gegen die KI-Aufrufe getestet. Sobald ein Angriff durchkommt, scheitert das Update.

18.6 Fallback wenn ein KI-Anbieter ausfällt

18.6.1 Mehrstufiger Fallback: Primär Mistral, sekundär Scaleway, tertiär AlephAlpha. Bei Ausfall des aktuellen Anbieters wird automatisch auf den nächsten umgeschaltet, der User merkt es nicht. 18.6.2 Bei kompletter Verfügbarkeits-Krise (alle drei down) zeigt die UI einen Klartext-Hinweis und einen sinnvollen Ersatz: - Lead-Zusammenfassung: „KI-Service gerade nicht verfügbar, Aktivitäts-Liste manuell durchgehen." - KI-Erstellung von Automatisierungen: „Du kannst die Automatisierung auch direkt im visuellen Editor bauen." - Programm-Hilfe-Chat: zeigt eine normale Volltext-Suche im Help-Center statt KI-Antwort. 18.6.3 Die Anbieter werden im Hintergrund alle 1 Minute auf Erreichbarkeit geprüft, ein ausgefallener Anbieter wird für 5 Minuten gesperrt und dann erneut probiert.

18.7 Caching (für Geschwindigkeit und Ausfallschutz)

18.7.1 Wenn dieselbe Frage mit denselben Daten erneut gestellt wird (z.B. dieselbe Lead-Zusammenfassung), wird die KI-Antwort aus einem Zwischenspeicher geliefert. Damit ist die Antwort sofort da und kostet keine zusätzlichen Tokens. 18.7.2 Der Zwischenspeicher funktioniert auch bei KI-Ausfall, gecachte Antworten bleiben verfügbar.

18.8 Verbrauch und Budget-Grenzen (Pay-as-you-go statt Pause) [N13, 09.05.2026]

Korrektur gem. Anmerkung Noah, 09.05.2026: KI-Funktionen dürfen nicht pausiert werden, ein Stillstand würde den Mandanten lähmen und das Versprechen der Plattform brechen. Stattdessen Vorbild Zapier / Cloud-Hyperscaler: bei Überschreitung des im Plan enthaltenen Tokens wird automatisch ein Verbrauchs-Aufschlag fällig. Vergleichsbild: Leasing-Vertrag mit eingeschlossenen Kilometern, darüber hinaus pro Kilometer.

18.8.1 Pro Mandant gibt es ein monatliches inklusives Token-Kontingent (Höhe abhängig vom Plan, konkrete Mengen mit Pricing-Festlegung, siehe H.1.1). 18.8.2 Bei 80% Verbrauch erscheint ein Klartext-Banner und eine Email an den Mandanten-Administrator: „KI-Budget zu 80% verbraucht. Wenn du das Inklusiv-Volumen überschreitest, werden zusätzliche Tokens automatisch zum Aufschlags-Tarif berechnet. [Plan upgraden] [Verbrauchs-Tarif ansehen]". 18.8.3 Bei 100% wird NICHT pausiert. Das System läuft uneingeschränkt weiter. Jede zusätzliche KI-Anfrage wird mit dem Aufschlags-Tarif (höherer Stückpreis als im Plan-Inklusivvolumen) abgerechnet. Klartext-Banner: „Inklusiv-Volumen verbraucht. Weitere Anfragen kosten ab jetzt [Aufschlags-Tarif] pro 1.000 Tokens. [Plan upgraden für mehr Inklusiv-Volumen]". 18.8.4 Aufschlags-Tarif ist transparent: pro Plan in den Subscription-Einstellungen sichtbar, pro KI-Funktionstyp gleicher Stückpreis. Konkrete Werte mit Pricing-Festlegung. 18.8.5 Upsell-Logik: - Wenn der Aufschlags-Verbrauch in einem Monat höher ist als die Differenz zum nächsten Plan, schlägt das System dem Mandanten-Administrator aktiv vor, das Abo zu upgraden („Du hast diesen Monat 87 Euro Aufschlag bezahlt. Mit Plan Cloud+ (49 Euro/Monat zusätzlich) wäre alles enthalten."). - Soft-Recommendation, kein Zwang. 18.8.6 Rechnungsstellung: Aufschlags-Verbrauch wird in der nächsten Legacy-Provider-Rechnung als Zusatzposition ausgewiesen. Mandant sieht in M28 (Subscription) den exakten Verbrauch nachvollziehbar. 18.8.7 Notbremse für Missbrauch: pro Mandant gibt es eine konfigurierbare absolute Obergrenze („nie mehr als X Euro Aufschlag pro Monat"). Wird sie erreicht, geht das System NICHT in Pause, sondern in einen Drosselungs-Modus mit Klartext-Warnung an den Administrator („Notbremse erreicht, ab jetzt nur noch geschäftskritische KI-Aufrufe (Klartext-Diagnostik). Sofortige Reaktion empfohlen."). Damit ist das Kostenrisiko gedeckelt, aber nichts geht schlagartig schwarz. 18.8.8 Reset des Inklusiv-Volumens zum Monatsersten. 18.8.9 Im Verbrauchs-Bereich des Mandanten-Administrators werden gezeigt: Verbrauch pro Anwendungsfall, Verbrauch über Zeit, Top-Verbraucher (welche Module / welche Nutzer), Hochrechnung Monatsende, aktueller Tarif, Notbremse-Stand.

18.9 DSGVO-Konformität

18.9.1 Alle KI-Anbieter haben einen Auftragsverarbeitungsvertrag mit uns, der EU-Daten-Verarbeitung garantiert. 18.9.2 Tenant-Daten werden niemals an US-Anbieter übermittelt (Hard-Constraint). 18.9.3 Die DSGVO-Konformität ist als verbindlicher Hinweis in den Tenant-Einstellungen hinterlegt und kann an Endkunden des Tenants weitergereicht werden.

18.10 Berechtigungen

18.10.1 Sechs feingranulare Berechtigungen: KI-Outputs sehen, Hilfe-Chat nutzen, Lead-Zusammenfassung generieren, Automatisierungs-Erstellung nutzen, Sprach-Transkription nutzen, voll administrieren. 18.10.2 Standard-Vergabe: Geschäftsführer voll, Vertriebsleiter und Projektleiter dürfen mehr Funktionen, Vertriebler/Büro dürfen Hilfe-Chat und Transkription, Monteur darf nur Sprach-Transkription (für Voice-Notes auf der Baustelle).

18.11 Phase 2 / bewusst NICHT in Phase 1

18.11.1 HiveMind als autonomer Agent: KI agiert ohne User-Trigger, schlägt selbständig Aktionen vor, führt geplante Aufgaben aus, versteht den aktuellen Bildschirm-Kontext. Erst nach Vertrauensgewinn aus Phase 1, wenn das Werkzeug-Modell sich etabliert hat. 18.11.2 Tenant-eigene Tools für die KI (z.B. der Tenant definiert eigene Aktionen, die der Agent ausführen darf), Phase 2. 18.11.3 Geplante autonome Aktionen (Cron-basiert ohne User-Trigger), Phase 2. 18.11.4 Eigene Anbieter-Schlüssel (Tenant bringt eigene Mistral/Scaleway-Accounts mit), Phase 2 (Enterprise). 18.11.5 Live-Streaming-Transkription (Text erscheint Wort für Wort beim Sprechen), Phase 2; Phase 1 ist Post-Recording.

18.12 Klartext-Fehlertexte (Beispiele)

18.12.1 KI-Anbieter aktuell down: „Die KI ist gerade nicht erreichbar. Wir versuchen es automatisch erneut. Du kannst alternativ den visuellen Editor nutzen." 18.12.2 Budget aufgebraucht: „KI-Budget für diesen Monat erschöpft. Ab dem 1. nächsten Monats läuft alles wieder. Erweiterung im Plan möglich (extern auf hivegrid.de/pricing)." 18.12.3 Eingabe zu lang: „Die Eingabe ist zu lang für die KI. Bitte kürzen oder in mehrere Anfragen aufteilen." 18.12.4 Sprach-Erkennung gescheitert: „Audio konnte nicht transkribiert werden, bitte erneut aufnehmen oder manuell tippen." 18.12.5 KI-Vorschlag mit Risiko: „Achtung: Dieser Filter könnte auch Wartungsverträge mit hohem Vertragswert treffen. Bitte vor dem Aktivieren prüfen."

Modul 19: KWP-Integration

Was es tut: Verbindet HiveGrid mit der bestehenden Geerkens-Buchhaltungs-Software KWP. Aufträge fließen aus HiveGrid in KWP (Won-Handoff), Stammdaten und Belege fließen aus KWP nach HiveGrid (Pull). Die Verbindung läuft über ein lokales Sync-Programm beim Kunden vor Ort, das mit der KWP-Datenbank spricht. Löst ab: Manuelle Doppel-Erfassung (heute kopiert Sandra Aufträge per Hand zwischen HubSpot und KWP), fehleranfällige Excel-Brücken. Warum es wichtig ist: USP-Säule „saubere Legacy-Anbindung" und Geerkens-Pflicht ohne Ausweg. KWP bleibt das System der Wahrheit für alles Buchhalterische: HiveGrid ist Cockpit und Vertriebs-Werkzeug, KWP bleibt die Basis für Rechnungs-Stellung, Buchhaltung und Steuer. HiveGrid liest aus KWP synchron, schreibt zurück über eine Warteschlange, kein Realtime-Beidseits-Sync, der lockt und Verwirrung erzeugt. Über das Adapter-Pattern aus Modul 33a wird KWP zur ersten konkreten App; Taifun und andere ERPs hängen sich später an dieselbe Schnittstelle.

19.1 Architektur in einem Satz

19.1.1 Drei Komponenten: (1) HiveGrid Cloud, (2) ein Sync-Programm beim Kunden vor Ort (auf einem Windows-Server bei Geerkens), (3) die KWP-Datenbank. Das Sync-Programm spricht lokal mit der KWP-Datenbank und tauscht über eine sichere Verbindung Daten mit der HiveGrid Cloud aus. 19.1.2 Die KWP-Zugangsdaten (Datenbank-Server, Datenbank-Name, Anmeldedaten zur Datenbank) liegen lokal beim Kunden: niemals in der Cloud. Damit verlassen die rohen Datenbank-Zugriffe das Geerkens-Netzwerk nicht.

19.2 Was synchronisiert wird

19.2.1 Aus HiveGrid nach KWP (Push): - Neuer Auftrag (entsteht typischerweise aus „Deal gewonnen" → automatisches Anlegen in KWP, mandanten-konfigurierbar auch sofort bei Deal-Anlage, siehe 3.6.7). - Status-Update zu einem bestehenden Auftrag. - Plantafel-Termine (siehe 4.6.14 für Details der bidirektionalen Plantafel-Sync) [N10, 09.05.2026]. 19.2.2 Aus KWP nach HiveGrid (Pull): - Stammdaten (Kunden, Lieferanten), bei Änderungen in KWP wird der HiveGrid-Stand aktualisiert. - Belege und Rechnungen. - Status-Änderungen an Aufträgen, die in KWP gemacht wurden. - Dokumenten-Archiv mit Spiegelung der KWP-Archiv-Struktur (siehe 19.2.5) [N5, 09.05.2026]. - Plantafel-Termine (siehe 4.6.14). 19.2.3 Pro Sync-Feature kann der Tenant-Admin einzeln entscheiden: aktiv oder nicht aktiv. 19.2.4 Die KWP-Auftragsnummern (Konvention z.B. „2026-0042") werden zentral pro Tenant verwaltet, fortlaufend pro Jahr, mit reservierten Nummern für Entwürfe (Reservierung läuft nach 24 Stunden ab, falls der Entwurf nicht abgeschickt wird). 19.2.5 Dokumenten-Archiv-Sync (KWP → HiveGrid, einseitig) [N5, 09.05.2026]

Erweiterung gem. Anmerkung Noah, 09.05.2026: KWP organisiert Dokumente in zwei Archiv-Ebenen: ein kundenspezifisches Gesamt-Archiv (alles, was zum Kunden über alle Aufträge hinweg gehört) und ein auftrags-/projekt-spezifisches Archiv (alles, was zum konkreten Auftrag gehört). Diese Struktur muss in HiveGrid gespiegelt werden. Sync-Richtung ist bewusst einseitig KWP → HiveGrid: alles, was in KWP entsteht, landet automatisch im passenden HiveGrid-Archiv. HiveGrid-Dokumente werden NICHT zurück nach KWP geschrieben, sonst läuft der KWP-Server voll.

• Pro Kunde in HiveGrid existiert ein Kunden-Archiv mit allen Dokumenten, die KWP zum Kunden ablegt (auftrags-übergreifend).
• Pro Projekt in HiveGrid existiert ein Projekt-Archiv mit den auftrags-spezifischen Dokumenten aus KWP.
• Beim Sync wird automatisch geprüft, in welche Archiv-Ebene das Dokument gehört (anhand der KWP-Verknüpfung Auftrag/Kunde) und in HiveGrid entsprechend abgelegt.
• Die Dokumente sind in HiveGrid lesbar, downloadbar, durchsuchbar (siehe Modul 23 und Modul 24).
• HiveGrid-Dokumente (z. B. signierte Angebote, Abnahme-Protokolle, hochgeladene Bilder) werden NICHT automatisch nach KWP gespiegelt. Mandant kann gezielt einzelne Dokumente nach KWP pushen, wenn explizit gewünscht (manueller Knopf „nach KWP übertragen", mit Klartext-Hinweis zur Speicher-Auswirkung).
• Sync-Erkennung pro Dokument: Quelle (KWP/HiveGrid), Erstellungsdatum in KWP, letzter Sync-Zeitpunkt. Sichtbar als Badge am Dokument.
• Lösch-Verhalten: wird ein Dokument in KWP gelöscht, bleibt es in HiveGrid mit Hinweis erhalten („In KWP gelöscht am [Datum]"), wird nach 30 Tagen Mandanten-konfigurierbar archiviert.

19.3 Sync-Richtung und Verantwortung

19.3.1 KWP ist und bleibt das System der Wahrheit für: Auftragsnummern, Rechnungen, Buchhaltung, Steuer-relevante Daten. Diese Daten werden in HiveGrid gespiegelt, nicht ersetzt. 19.3.2 HiveGrid ist das System der Wahrheit für: Vertriebs-Aktivitäten, Pipeline-Status (vor Won), Lead-Daten, Kommunikation, Termine, Tasks, Forms. 19.3.3 Push aus HiveGrid nach KWP läuft über eine Warteschlange (nicht direkt). Damit ist garantiert: bei kurzen Aussetzern wird nichts verloren, alle Operationen werden zuverlässig zugestellt. 19.3.4 Pull aus KWP nach HiveGrid läuft regelmäßig (Standard alle 30 Sekunden, vom Tenant-Admin anpassbar). Die HiveGrid-Daten sind also nahezu in Echtzeit, aber ohne den Risiko-Charakter eines Realtime-Beidseits-Sync.

19.4 Setup beim Kunden

19.4.1 Geführter Setup-Wizard im HiveGrid-Tenant-Admin-Bereich: 1. Voraussetzungs-Check in Klartext: „Du brauchst Admin-Zugang zur KWP-Datenbank. Das Sync-Programm muss auf einem Server laufen, der KWP erreicht. Bestätigen." 2. Token-Erstellung (Cloud-API-Schlüssel für das Sync-Programm), einmalig sichtbar, mit Klartext-Warnung zum sicheren Speichern. 3. Download des Sync-Programms (signiertes Installer-Paket). 4. Lokale Konfiguration: HiveGrid-API-Adresse, Token, KWP-Datenbank-Verbindung (lokal), Registrierung als Windows-Service. 5. Initial-Verbindungs-Test: HiveGrid wartet auf das erste Lebenszeichen vom Sync-Programm und bestätigt in Klartext. 6. Optional: Initial-Sync der Bestandsdaten mit Klartext-Vorschau („1.247 Kontakte und 384 Aufträge aus KWP übernehmen?") und sichtbarem Fortschritt. 19.4.2 Nach erfolgreichem Setup wählt der Tenant-Admin, welche Sync-Features aktiv sein sollen (alle standardmäßig an).

19.5 Sync-Programm beim Kunden vor Ort (Heartbeat und Selbstheilung)

19.5.1 Das Sync-Programm läuft als Windows-Service auf einem Server bei Geerkens (Windows 10+ oder Server 2016+). Damit startet es automatisch beim Boot und wird vom Windows-Service-Manager bei Crash neu gestartet. 19.5.2 Lebenszeichen (Heartbeat) alle 5 Minuten an die HiveGrid Cloud. Bleibt das Lebenszeichen 15 Minuten aus, wird der Status der Verbindung auf defekt gesetzt und der Tenant-Admin plus wir als Plattform-Anbieter werden per Klartext-Email und Push informiert. 19.5.3 Klartext bei defekter Verbindung: „Sync-Programm beim Kunden vor Ort ist nicht erreichbar. Mögliche Ursachen: Windows-Update läuft, Service wurde gestoppt, Server-Reboot. Anleitung: [Schritt-für-Schritt]" 19.5.4 Automatische Updates des Sync-Programms: täglicher Check auf neue Version, signiertes Update-Paket, Auto-Update bei Tenant-Admin-Opt-In, oder manuelles Update über die HiveGrid-UI mit Download-Link. 19.5.5 Die lokale Konfigurations-Datei (mit Verbindungs-Daten und Token) wird mit Windows-Bordmitteln verschlüsselt gespeichert (DPAPI). Logs liegen lokal in einem rotierenden Verzeichnis.

19.6 Konfliktlösung bei parallelem Bearbeiten [N14, 09.05.2026]

Problem (real bei Geerkens): Sandra editiert in KWP, Noah parallel in HiveGrid denselben Auftrag. Wer gewinnt?

Korrektur gem. Anmerkung Noah, 09.05.2026: In der Praxis wird in KWP wenig geändert (Kundenzuweisung, Status, Rechnung). Wenn aber etwas in KWP geändert wird, ist es meist buchhalterisch relevant, im Worst Case eine Rechnung. KWP ist der buchhalterische Grundstock und steht oberhalb von HiveGrid in der Synchronisations-Hierarchie. Daher gilt nicht „letzter gewinnt", sondern: bei Konflikten gewinnt immer KWP.

19.6.1 Default-Regel: KWP gewinnt immer. Wenn ein KWP-Sync einen HiveGrid-Stand überschreibt (Felder wie Kundenzuweisung, Status, Rechnungs-Daten, Adresse), wird der KWP-Stand übernommen, und der HiveGrid-Bearbeiter bekommt eine Klartext-Benachrichtigung: „Dein Edit von 14:19 wurde durch eine KWP-Änderung überschrieben (Sandra in KWP, 14:23). Dein vorheriger Stand: [Anzeigen] [In Notiz übernehmen]". So ist die Datenhoheit eindeutig. 19.6.2 HiveGrid-eigene Felder bleiben unangetastet: Felder, die HiveGrid pflegt und KWP gar nicht kennt (Pipeline-Stufe vor Won, Lead-Daten, interne Notizen, Aktivitäts-Strom, Aufgaben-Verknüpfungen, Kommunikation), werden vom KWP-Sync nicht überschrieben. 19.6.3 Versions-Schutz auf HiveGrid-Seite: Beim Laden eines Auftrags wird der Stand gemerkt. Kommt zwischen Laden und Speichern eine KWP-Änderung an, wird das Speichern auf den überschnittenen KWP-Feldern blockiert und ein Vergleich („Diff") gezeigt: „Während du editiert hast, kam eine Änderung aus KWP rein. KWP gewinnt automatisch in den überschnittenen Feldern. Hier die Differenz. Deine Änderungen in den HiveGrid-eigenen Feldern werden gespeichert.". 19.6.4 Visueller Hinweis „gerade in KWP bearbeitet": Wenn das Sync-Programm erkennt, dass jemand parallel in KWP an demselben Auftrag arbeitet, zeigt HiveGrid eine Warnung: „KWP-Bearbeitung erkannt seit deinem letzten Aufruf. Dein Edit gilt nur für HiveGrid-Felder, KWP-Felder werden vom KWP-Stand überschrieben.". 19.6.5 Audit-Trail: jeder KWP-gewinnt-Vorgang wird im Audit-Log mit dem überschriebenen vorherigen HiveGrid-Stand vermerkt, damit nichts unwiederherstellbar verloren geht. Restore aus dem Audit ist über den Plattform-Admin möglich (Sonderfall, Klartext-Hinweis).

19.7 Persistente Warteschlange und kontrollierte Wiederaufnahme nach Ausfall

Problem (real): HiveGrid Cloud ist 6 Stunden down, in der Zwischenzeit fallen 1.230 Operationen an. Was passiert beim Wiederhochfahren?

19.7.1 Zwei Warteschlangen sorgen für Doppelte Sicherheit: - Cloud-seitige Warteschlange für Push-Operationen aus HiveGrid Richtung KWP. - Lokale Warteschlange (im Sync-Programm) für Pull-Daten, falls die Cloud nicht erreichbar ist. 19.7.2 Nach einem Ausfall wird die Warteschlange chronologisch und gedrosselt abgearbeitet: maximal 100 Operationen pro Minute, mit sichtbarem Fortschritt: „Re-Sync läuft, 847/1.230 abgearbeitet (4 Min verbleibend)" 19.7.3 Bei Konflikten zwischen Warteschlange und aktuellem HiveGrid-Stand: Pause + Klartext-Konflikt-Ansicht: „Auftrag #4729 wurde in beiden Systemen editiert. Welcher Stand soll gelten? [HiveGrid] [KWP-Warteschlange] [Manuell zusammenführen]"

19.8 Schema-Drift-Sentinel (Schutz gegen unangekündigte KWP-Updates)

Problem (real, Pre-mortem-Risiko): KWP ändert mit einem Update Tabellen oder Felder. Ohne Schutz würde der Sync still falsche Daten schreiben.

19.8.1 Tageslauf prüft das KWP-Datenmodell auf Veränderungen. Erkannte Änderungen erzeugen einen kritischen Eintrag im System. 19.8.2 Bei erkannter Änderung wird der Sync automatisch pausiert: Sicherheit geht vor Verfügbarkeit. Zuerst werden wir als Plattform-Anbieter informiert, nicht der Tenant. 19.8.3 Der Tenant sieht lediglich den Klartext: „KWP-Update erkannt, manche Felder wurden geändert. Sync pausiert für Sicherheit. Wir sind informiert und beheben das." 19.8.4 Nach Anpassung der Anbindungs-Logik durch uns wird der Sync wieder freigegeben (mit Audit-Eintrag).

19.9 Fehler-Berichte und Auditierbarkeit

19.9.1 Pro auftretendem Fehler wird ein Klartext-Fehlerbericht erzeugt, mit Schweregrad (Info, Warnung, Fehler, Kritisch), Zeitpunkt, Klartext-Zusammenfassung und einem Bereich mit technischen Details (nur für uns Plattform-Admins sichtbar). 19.9.2 Der Tenant-Admin kann Fehlerberichte ansehen, als „zur Kenntnis genommen" markieren und filtern (nach Datum, Schweregrad, Art). 19.9.3 Jede Schreib-Operation in beide Richtungen wird auditierbar geloggt (wer/was/wann).

19.10 Berechtigungen

19.10.1 Sechs feingranulare Berechtigungen: Status sehen, Setup-Wizard durchführen, Verbindung verwalten, manuell synchronisieren, Verbindung trennen, voll administrieren (letztere ist Plattform-Admin-exklusiv: bei Schema-Drift kann nur der Plattform-Admin den Sync wieder freigeben). 19.10.2 Standard-Vergabe: Geschäftsführer darf alles bis auf Schema-Drift-Bypass, Büro/Backoffice darf manuell syncen, Plattform-Admin (wir) hat das letzte Wort bei strukturellen Themen.

19.11 Phase 2 / bewusst NICHT in Phase 1

19.11.1 Andere ERPs (Taifun, TopKontor, Streit V.1), über dasselbe Adapter-Pattern, aber erst mit zahlendem Kunden. Taifun arbeitet vermutlich analog zu KWP (lokales Sync-Programm), Streit V.1 hat möglicherweise eine Cloud-API. 19.11.2 Native KWP-API: Falls der KWP-Geschäftsführer-Termin erfolgreich verläuft und eine offizielle API freigegeben wird, kann das Sync-Programm-Modell durch eine direkte API-Anbindung ersetzt werden. Das würde die Architektur stark vereinfachen. 19.11.3 Trigger-basierter Pull aus KWP (KWP meldet Änderungen aktiv, statt regelmäßig abgefragt zu werden), Phase 2. 19.11.4 Bidirektionaler Realtime-Sync in beide Richtungen, bewusst Phase 2 oder gar nicht. Realtime in beide Richtungen erzeugt schwer fassbare Konflikte und Verwirrung. Phase 1 ist „Pull synchron, Push über Warteschlange", bewusst entkoppelt.

19.12 Klartext-Fehlertexte (Beispiele)

19.12.1 Sync-Programm offline: „Sync-Programm beim Kunden vor Ort ist nicht erreichbar. Mögliche Ursachen: Windows-Update läuft, Service wurde gestoppt, Server-Reboot. [Anleitung] [Verbindung erneut aufbauen]" 19.12.2 Schema-Drift: „KWP-Update erkannt, manche Felder wurden geändert. Sync pausiert für Sicherheit. Wir sind informiert und beheben das." 19.12.3 Konflikt: „Auftrag #4729 wurde in beiden Systemen editiert. Welcher Stand soll gelten? [HiveGrid] [KWP-Warteschlange] [Manuell zusammenführen]" 19.12.4 Token abgelaufen: „Der Verbindungs-Token ist abgelaufen. Bitte in den Einstellungen einen neuen Token erstellen und im Sync-Programm hinterlegen." 19.12.5 Datenbank-Verbindung verloren: „Das Sync-Programm erreicht die KWP-Datenbank nicht. Mögliche Ursachen: KWP-Server läuft nicht, Netzwerk-Problem, falsche Verbindungs-Daten. [Anleitung]" 19.12.6 Re-Sync nach Outage: „Re-Sync läuft, 847 von 1.230 Operationen abgearbeitet (4 Minuten verbleibend). Du kannst HiveGrid normal weiternutzen, neue Änderungen werden hinten an die Warteschlange angehängt."

Block 5: Kommunikation

Sechs Module, die alle Kommunikations-Kanäle in HiveGrid abbilden: Email-Posteingang mit Sync zu Gmail und Outlook, Email-Marketing als HubSpot-Marketing-Ablösung, Telefonie über AirCall, interner Team-Chat, Push-/Email-/In-App-Benachrichtigungen, und bidirektionale Kalender-Synchronisation.

Modul 9: Email-Inbox

Was es tut: Verbindet die Email-Postfächer der Mitarbeiter (Gmail, Outlook) mit HiveGrid, sodass jede ein- und ausgehende Mail automatisch dem richtigen Kontakt, Deal oder Projekt zugeordnet wird und im Aktivitäts-Verlauf sichtbar ist. Schickt eigene Mails über das verbundene Postfach des Mitarbeiters raus, sodass die Mail nativ im "Gesendet"-Ordner des Mitarbeiters landet.

Löst ab: HubSpot-Email-Tools (Posteingang-Anbindung, Mail-Tracking, Verknüpfung mit CRM).

Warum es wichtig ist: Ohne Mailbox-Anbindung bleibt das CRM blind für 70% der Kundenkommunikation. Jede Mail manuell ins CRM kopieren ist genau die Sklaverei, von der HiveGrid den Handwerker befreien soll.

9.1 Welche Email-Anbieter werden unterstützt

9.1.1 Phase 1 unterstützt Gmail (inkl. Google Workspace) und Microsoft Outlook / Microsoft 365. 9.1.2 Andere Anbieter (eigene IMAP-Server, T-Online, GMX, Web.de) sind in Phase 1 nicht unterstützt, Hinweis im Setup: "Aktuell nur Gmail und Outlook. Andere Anbieter folgen in einer späteren Version." 9.1.3 Pro Mitarbeiter können mehrere Postfächer verbunden werden (z.B. privat + dienstlich), eines wird als "Standard-Postfach" markiert. 9.1.4 Die Anmeldung an Gmail/Outlook erfolgt einmalig per offiziellem Login-Fenster des Anbieters; HiveGrid sieht das Passwort des Mitarbeiters nie.

9.2 Was im Posteingang sichtbar ist

9.2.1 Eine Listen-Ansicht aller verbundenen Mails mit Absender, Betreff, ersten Zeilen der Mail, Empfangsdatum, Lese-Status und Anhang-Anzeige. 9.2.2 Filter nach: Postfach (wenn mehrere), Eingang/Ausgang, gelesen/ungelesen, verknüpft mit Kontakt/Deal/Projekt/nicht verknüpft, Datums-Bereich, Anhang vorhanden. 9.2.3 Volltext-Suche über Betreff, Inhalt und Absender. 9.2.4 Detail-Ansicht zeigt die komplette Mail (mit Anhängen herunterladbar), den verknüpften Kontakt/Deal/Projekt, den kompletten Mail-Verlauf (Thread, alle Antworten chronologisch) und Funktionen "Antworten / Allen antworten / Weiterleiten". 9.2.5 Externe Bilder in Mails sind aus Sicherheitsgründen erst nach explizitem Klick "Bilder anzeigen" sichtbar (Schutz vor Tracking-Pixeln). 9.2.6 Mails, die HiveGrid keinem Kontakt zuordnen konnte, zeigen einen Hinweis: "Diese Mail ist keinem Kontakt zugeordnet, [Zu Kontakt zuordnen] [Neuen Kontakt anlegen]". 9.2.7 Mark-as-read und Archivieren werden zum Postfach zurück synchronisiert (was im HiveGrid als gelesen markiert wird, ist auch in Gmail/Outlook gelesen).

9.3 Verknüpfung mit Kontakten und Deals (Auto-Zuordnung)

9.3.1 Über die Email-Adresse: Stimmt die Absender- (oder Empfänger-) Adresse exakt mit der Email eines bestehenden Kontakts oder Leads überein, wird die Mail automatisch dem Kontakt zugeordnet. 9.3.2 Über Betreff-Kürzel: Enthält der Betreff Kennungen wie [Deal #123], [Auftrag #456] oder [Lead #789], wird die Mail automatisch dem entsprechenden Vorgang zugeordnet. 9.3.3 Heuristisch über Kontakt + offene Deals: Hat der zugeordnete Kontakt genau einen offenen Deal, wird die Mail diesem Deal vorgeschlagen (mittlere Sicherheit, sichtbar markiert). 9.3.4 Manuelle Korrektur: Jede Auto-Zuordnung kann der Mitarbeiter im Detail-View überschreiben (Mail einem anderen Kontakt/Deal/Projekt zuordnen). Manuelle Zuordnung wird respektiert und nicht automatisch überschrieben. 9.3.5 Bei mehreren Kontakten mit gleicher Email-Adresse wird der primäre Kontakt gewählt mit Hinweis: "Diese Email gehört zu mehreren Kontakten. Aktuell zugeordnet: [Name]." 9.3.6 Newsletter und Bulk-Mails (erkennbar an Kopfzeilen) werden nicht automatisch verknüpft, sondern als "Newsletter / Bulk" markiert.

9.4 Eigene Sende-Domain mit Echtheits-Schutz

9.4.1 Damit der Handwerker Marketing-Mails (Modul 10) und Bestätigungs-Mails (Booking, Acceptance) unter seiner eigenen Domain (z.B. info@geerkens.de) versenden kann, muss diese Domain einmalig im HiveGrid verifiziert werden. 9.4.2 HiveGrid generiert drei DNS-Einträge (Email-Echtheits-Schutz: DKIM, SPF, DMARC) und zeigt sie als Klartext-Anleitung mit Copy-to-Clipboard-Funktion an: "Diese 3 Einträge bei deinem DNS-Anbieter (Strato, Hetzner, IONOS, Cloudflare) anlegen. Wir prüfen automatisch alle 5 Minuten." 9.4.3 Sobald HiveGrid die Einträge findet, wird die Domain auf "verifiziert" gesetzt und kann für Versand benutzt werden. 9.4.4 Findet HiveGrid die Einträge 7 Tage lang nicht, wird die Verifikation abgebrochen mit Klartext: "DNS-Einträge nach 7 Tagen nicht gefunden. [Anleitung erneut anzeigen] [Support kontaktieren]". 9.4.5 Ohne verifizierte Domain ist Marketing-Versand nicht möglich (Modul 10 blockiert mit Hinweis); transaktionale Mails (Booking-Bestätigung, Passwort-Reset) gehen ersatzweise über die HiveGrid-Standard-Domain mit Tenant-Branding. 9.4.6 Die Einrichtung der Sende-Domain ist ein einmaliger Vorgang pro Handwerksbetrieb (nicht pro Mitarbeiter).

9.5 Mailbox-Synchronisation

9.5.1 HiveGrid empfängt neue Mails über sofortige Push-Benachrichtigungen vom Anbieter (kein verzögertes Abfragen alle 15 Minuten). Eine neue Mail erscheint in der Regel innerhalb weniger Sekunden im HiveGrid-Posteingang. 9.5.2 Beim ersten Verbinden eines Postfachs werden die letzten 90 Tage Mail-Historie geladen (Standard, später konfigurierbar). Während des Initial-Imports zeigt HiveGrid einen Fortschrittsbalken: "Initial-Sync läuft, 1.234 von 5.678 Mails geladen (22%)". 9.5.3 Geht die Verbindung zum Postfach verloren (z.B. weil der Mitarbeiter die HiveGrid-Berechtigung in Gmail widerrufen hat), wird der Status auf "Verbindung unterbrochen" gesetzt und der Mitarbeiter bekommt eine Klartext-Mitteilung: "Deine Gmail-Verbindung wurde unterbrochen, bitte erneut verbinden. [Verbindung erneuern]". 9.5.4 Die automatische Wieder-Anmeldung (Token-Refresh) läuft im Hintergrund, sodass eine einmal verbundene Mailbox monatelang stabil bleibt. 9.5.5 Sollten die Push-Benachrichtigungen länger als 4 Stunden ausbleiben, prüft HiveGrid sicherheitshalber stündlich aktiv nach (Sicherheitsnetz).

9.6 Quotenschutz und Spam

9.6.1 Pro Anbieter gibt es Versand-Limits (Gmail: 1 Milliarde Anfragen pro Tag, Microsoft: 10.000 Mails/Tag pro Postfach). HiveGrid drosselt automatisch, bevor diese Limits gerissen werden. 9.6.2 Schickt Gmail/Outlook eine "Quota überschritten"-Meldung zurück, erscheint Klartext: "Du hast das tägliche Sende-Limit erreicht. Es wird in [X Stunden] zurückgesetzt." 9.6.3 Eingehende Mails, die der Anbieter als Spam markiert hat, werden im HiveGrid mit einem Spam-Hinweis versehen, aber nicht automatisch ausgeblendet (der Mitarbeiter entscheidet).

9.7 Schreiben und Versenden eigener Mails

9.7.1 Mail-Schreiben kann aus dem Kontakt-/Deal-/Projekt-Detail heraus gestartet werden (Empfänger und Betreff werden vorausgefüllt) oder aus dem Posteingang (Antworten / Weiterleiten). 9.7.2 Texteditor mit Formatierung (fett, kursiv, Listen, Bilder einbetten), Anhänge bis 25 MB pro Mail (Anbieter-Limit). 9.7.3 Mehrere Postfächer verbunden: der Absender wird vor dem Senden gewählt (Standard-Postfach des Mitarbeiters voreingestellt). 9.7.4 Die Mail wird nativ über das verbundene Postfach versendet, sie erscheint im "Gesendet"-Ordner des Mitarbeiters in Gmail/Outlook (so als hätte er sie dort geschrieben). 9.7.5 Optional: BCC-Logging-Adresse, damit auch Mails, die der Mitarbeiter aus dem nativen Gmail/Outlook schreibt, automatisch im CRM landen.

9.8 Berechtigungen

9.8.1 Eigene Mails sehen: der Mitarbeiter sieht nur Mails aus seinem eigenen verbundenen Postfach. 9.8.2 Alle Mails sehen: Vorgesetzte/Backoffice können alle Mails aller Postfächer im Betrieb sehen. 9.8.3 Mails schreiben: der Mitarbeiter kann Mails aus dem eigenen Postfach versenden. 9.8.4 Email-Admin: Sende-Domain einrichten, fremde Postfach-Verbindungen trennen. 9.8.5 Die Aktivitäten am Kontakt respektieren diese Berechtigungen: Wer nur "eigene Mails sehen" darf, sieht am Kontakt nur die Mails aus seinem Postfach.

9.9 Phase 2 / bewusst NICHT in Phase 1

9.9.1 Andere Email-Anbieter (T-Online, GMX, eigene IMAP-Server). 9.9.2 Geplanter Versand ("Mail um Datum X versenden"). 9.9.3 Snooze-Funktion (Mail kommt in 3 Tagen wieder in Inbox). 9.9.4 Auto-Weiterleitungs-Regeln (alle Mails von Domain X an Sales-Team). 9.9.5 Shared-Inbox (mehrere Mitarbeiter teilen sich ein Postfach mit Zuweisung). 9.9.6 Tenant-konfigurierbare Betreff-Kürzel für Auto-Zuordnung. 9.9.7 Unified Inbox mit weiteren Kanälen (Email + WhatsApp + perspektivisch weitere Messaging-Quellen) [N15, 09.05.2026]: pro Abteilung oder pro Projekt eine gemeinsame Sicht über alle Kommunikations-Kanäle. Vorbild Superchat. Alle Nachrichten sind dem Projekt/Kontakt zugeordnet, Mitarbeiter sehen, was beim Kollegen angekommen ist (Informations-Redundanz, Transparenz). Bedeutet ein eigenes Sub-Modul mit WhatsApp-Adapter (heute Anti-Liste, siehe Vision V.3.2.3) und Konversations-Threading über Kanal-Grenzen. Phase 2.

9.10 Klartext-Fehlertexte (Beispiele)

9.10.1 "Deine Gmail-Verbindung wurde unterbrochen, bitte erneut verbinden. [Verbindung erneuern]" 9.10.2 "Wir konnten Google nicht erreichen. Wir versuchen es erneut in 5 Min. [Manuell prüfen]" 9.10.3 "Du hast das tägliche Sende-Limit erreicht. Es wird in [X Stunden] zurückgesetzt." 9.10.4 "Outlook-Verbindung abgelaufen, bitte erneut verbinden." 9.10.5 "DNS-Einträge nach 7 Tagen nicht gefunden. [Anleitung erneut anzeigen]" 9.10.6 "Du hast keine Mailbox verbunden. [Mailbox verbinden]" 9.10.7 "Der Kontakt hat keine Email-Adresse hinterlegt. [Email ergänzen]"

Modul 10: Email-Marketing

Was es tut: Versendet Newsletter, Wartungs-Erinnerungen, Service-Aktionen und automatische Trigger-Mails an Empfänger-Listen aus dem CRM. Trackt Öffnungen und Klicks, behandelt automatisch Rückläufer (Bounces), verwaltet Abmeldungen DSGVO-konform und stellt der Automation-Engine (Modul 17) eine Aktion "Marketing-Mail senden" zur Verfügung.

Löst ab: HubSpot-Marketing-Hub.

Warum es wichtig ist: Marketing-Mails sind die Standard-Erinnerungs- und Akquise-Schiene im SHK-Geschäft (Wartungs-Erinnerungen, Saison-Aktionen, Newsletter). Ohne dieses Modul müsste Geerkens HubSpot-Marketing-Hub weiter zahlen oder zu einem fremden Tool wie Brevo/Mailchimp wechseln.

10.1 Newsletter und Sequenzen

10.1.1 Eine Kampagne ist eine einmalige Mail-Aussendung an eine definierte Empfänger-Liste (Sofort-Versand oder geplant für späteren Zeitpunkt). 10.1.2 Der Kampagnen-Builder führt in Schritten durch: Basis-Daten (Name, Betreff, Vorschau-Text, Absender wählen) → Inhalt (Texteditor mit Personalisierungs-Platzhaltern) → Empfänger wählen → Test-Mail an sich selbst senden → Versand-Zeitpunkt → Bestätigung. 10.1.3 Personalisierungs-Platzhalter im Mail-Text werden pro Empfänger ersetzt: {{first_name}}, {{last_name}}, {{company_name}} und beliebige eigene Felder (z.B. {{custom.heizungs_modell}}). 10.1.4 Vorlagen (Templates) sind wiederverwendbare Mail-Designs. SHK-Standard-Vorlagen werden mit dem Account ausgeliefert: "Wartungs-Erinnerung", "Newsletter Q4", "Service-Aktion" (Vorlagen sind anpassbar). 10.1.5 Vorschau-Funktion rendert die Mail Desktop- und Mobile-Breite und zeigt mit Beispieldaten, wie sie beim Empfänger ankommt. 10.1.6 Sequenzen (Mail 1 → 3 Tage warten → Mail 2 → 7 Tage → Mail 3) sind Phase 2, in Phase 1 werden zeitliche Abfolgen über die Automation-Engine (Modul 17) gebaut.

10.2 Empfänger-Listen und Segmentierung

10.2.1 Segmente sind gespeicherte Filter über die Kontakt-Datenbank. Beispiele: "Alle Kontakte mit Wartungsvertrag", "Alle Endkunden mit Lifecycle = Kunde, Sprache Deutsch", "Alle Kontakte mit Tag 'Newsletter' UND letzter Auftrag älter als 365 Tage". 10.2.2 Filter-Kriterien: Tags (UND/ODER), Lifecycle-Stage, eigene Felder, Verantwortlicher Mitarbeiter, Erstellt-Datum, verknüpft mit aktivem Deal, letzte Aktivität, Endkunde-Flag, Sprache. 10.2.3 Verschachtelte UND/ODER-Bäume sind möglich (z.B. "Tag = Newsletter UND (Wartungsvertrag = Ja ODER Lifecycle = Kunde)"). 10.2.4 Live-Vorschau: das Segment zeigt jederzeit die aktuell zutreffende Empfänger-Anzahl und eine Stichprobe von 50 Beispiel-Kontakten. 10.2.5 Statisches vs. dynamisches Segment: Default ist dynamisch (Empfänger wird bei jedem Versand neu berechnet). Statisch friert die Liste zum Anlage-Zeitpunkt ein (Use-Case: "Genau diese 247 Kunden bekommen die Aktion"). 10.2.6 Auto-Ausschluss bei Versand: Empfänger ohne dokumentierte Marketing-Einwilligung, in der Sperrliste, ohne Email-Adresse, archiviert oder bereits abgemeldet werden automatisch ausgeschlossen. Die Versand-Bestätigung zeigt Klartext: "X aus Y Empfängern werden ausgeschlossen (Abmeldung / Hard-Bounce / Sperrliste / fehlende Einwilligung)".

10.3 A/B-Tests

10.3.1 A/B-Tests (Variante A vs. Variante B mit unterschiedlichem Betreff oder Inhalt, automatischer Versand des Gewinners an den Rest) sind Phase 2. 10.3.2 In Phase 1 kann der Betrieb manuell zwei Kampagnen an Test-Segmente versenden und das Ergebnis manuell vergleichen.

10.4 Tracking (Öffnungen, Klicks, Bounces, Beschwerden)

10.4.1 Pro Kampagne werden gezählt: versendet, zugestellt, hart zurückgekommen (Adresse existiert nicht), weich zurückgekommen (Mailbox voll), geöffnet (eindeutig pro Empfänger), geklickt, abgemeldet, Spam-Beschwerden. 10.4.2 Daraus errechnet HiveGrid: Zustellrate, Öffnungsrate, Klickrate, Klick-zu-Öffnungs-Rate, Abmelde-Rate. 10.4.3 Klick-Karte: zeigt welche Links wie oft geklickt wurden (sortiert nach Klick-Häufigkeit). 10.4.4 Pro-Empfänger-Liste: tabellarisch alle Empfänger der Kampagne mit Status (zugestellt, geöffnet wann, geklickt was, abgemeldet wann). 10.4.5 Aggregat am Kontakt: im Kontakt-Detail erscheint "Marketing-Engagement: 12 Mails erhalten, 8 geöffnet (66%), 3 geklickt (25%), 0 abgemeldet", sichtbar auch ohne Marketing-Berechtigung (ohne Detail welche Kampagne). 10.4.6 Datenschutz-Hinweis: Im Mail-Footer steht "Diese Mail enthält einen Tracking-Pixel" (DSGVO-Pflicht).

10.5 Unsubscribe-Pflicht (DSGVO-Pflicht)

10.5.1 Jede Marketing-Mail enthält automatisch einen Abmelde-Link im Footer. Wenn der Mitarbeiter den Link beim Schreiben vergisst, fügt HiveGrid ihn beim Versand zwingend ein. 10.5.2 Klick auf den Abmelde-Link öffnet eine öffentliche Abmelde-Seite (kein Login nötig) mit Klartext: "Du wirst von Marketing-Mails von [Betriebs-Name] abgemeldet. [Abmeldung bestätigen]". 10.5.3 Optional kann der Empfänger einen Grund auswählen (zu häufig / nicht relevant / Spam / sonstiges) und Freitext-Feedback geben. 10.5.4 Nach Bestätigung erscheint: "Du bist abgemeldet. Wir senden keine weiteren Marketing-Mails an [Email]. Falls das ein Versehen war: [Wieder anmelden]". 10.5.5 Abgemeldete Adressen werden dauerhaft auf eine Sperrliste pro Betrieb gesetzt; auch wenn der Kontakt im CRM gelöscht und neu angelegt wird, bleibt die Adresse gesperrt. 10.5.6 Ein-Klick-Abmeldung über speziellen Mail-Header für Gmail/Apple Mail: der Empfänger kann direkt in Gmail "Abmelden" klicken, ohne die Abmelde-Seite zu öffnen.

10.6 Bounce-Handling

10.6.1 Hard-Bounce (Adresse existiert nicht, Domain existiert nicht, Mailbox blockiert): die Adresse wird automatisch auf die Sperrliste gesetzt. Künftige Marketing-Versendungen blockiert. Im Kontakt-Detail erscheint Klartext: "Email-Adresse als ungültig markiert (Hard-Bounce am [Datum]). Marketing-Mails werden nicht mehr an diese Adresse gesendet. [Adresse korrigieren] [Trotzdem verwenden]". 10.6.2 Soft-Bounce (Mailbox temporär voll, Server kurz down): bis zu 3-mal über 24 Stunden erneut versucht. Bleibt es bei 3 Fehlversuchen, wird wie Hard-Bounce behandelt. 10.6.3 Spam-Beschwerden: meldet der Empfänger die Mail als Spam (über sein Mail-Programm), wird der Kontakt automatisch abgemeldet und die Adresse gesperrt. Im Kontakt-Aktivitäts-Verlauf erscheint: "Empfänger hat sich beschwert, automatisch abgemeldet".

10.7 DSGVO-Marketing-Einwilligungen (kritisch)

10.7.1 Einwilligung dokumentieren ist Pflicht: zu jedem Kontakt wird festgehalten WANN, WOHER und MIT WELCHEM TEXT er der Marketing-Kommunikation zugestimmt hat (Form-Submission, manueller Import, bestehender Kunde, Double-Opt-In-Bestätigung). 10.7.2 Kontakte ohne dokumentierte Einwilligung werden beim Versand automatisch ausgeschlossen (kein Versand möglich). 10.7.3 Double-Opt-In: trägt sich ein Endkunde in ein Anmelde-Formular ein, sendet HiveGrid eine Bestätigungs-Mail mit Bestätigungs-Link. Erst nach Klick gilt die Einwilligung als erteilt. Der Bestätigungs-Link ist 7 Tage gültig. 10.7.4 Bei einer Kampagne mit weniger als 50% einwilligenden Empfängern erscheint Warnhinweis: "Nur X% deiner Empfänger haben dokumentierte Einwilligung. Die anderen werden ausgeschlossen. [Mehr lernen]". 10.7.5 Pflicht-Inhalte im Mail-Footer: physische Absender-Adresse (Impressum nach DSGVO), Abmelde-Link. Versand wird blockiert, wenn HiveGrid keine Adresse erkennt, Klartext: "Im Footer fehlt die Absender-Adresse (DSGVO-Pflicht). [Footer ergänzen]".

10.8 Trigger-Mails über die Automation-Engine

10.8.1 Modul 17 (Automation) bietet die Aktion "Marketing-Mail senden" in Wenn-Dann-Regeln. 10.8.2 Konfiguration: Vorlage wählen (Pflicht), Absender wählen, Empfänger aus Auslöse-Kontext bestimmen ("an den Kontakt des ausgelösten Deals"), Personalisierungs-Werte aus dem Auslöser nutzen. 10.8.3 Beispiele für Geerkens: "Wenn neuer Lead aus Formular → 1h später Bestätigungs-Mail mit Terminvorschlag", "Wenn letzte Wartung > 365 Tage → Wartungs-Erinnerung", "Wenn Deal-Stage = 'Angebot offen' für 7 Tage → Erinnerungs-Mail". 10.8.4 Auto-Ausschluss greift auch hier: ist der Empfänger abgemeldet oder gesperrt, wird die Trigger-Mail nicht gesendet (Aktivitäts-Eintrag: "Trigger-Mail blockiert, Empfänger abgemeldet").

10.9 Anti-Spam-Schutz (Schutz für die eigene Sender-Reputation)

10.9.1 Tages-Limit pro Betrieb: Cloud-Plan 10.000 Mails/Tag, Cloud-Plus 50.000/Tag, Enterprise individuell, Trial 200/Tag (gegen Missbrauch). Bei Überschreitung pausiert der Versand mit Klartext: "Tägliches Sende-Limit erreicht. Versand wird morgen 00:00 fortgesetzt". 10.9.2 Frequenz-Schutz pro Empfänger: maximal 5 Marketing-Mails pro Empfänger pro Woche (verhindert Belästigung, anpassbar im Admin-Bereich). 10.9.3 Spam-Check vor Versand: der Mail-Inhalt wird gegen einfache Regeln geprüft (übermäßiger Großschrift-Einsatz, zu viele Ausrufezeichen, Verdachts-Phrasen wie "KOSTENLOS!!!", Bilder/Text-Verhältnis). Spam-Score 0-10 wird mit Empfehlungen angezeigt; ab Score >7 erscheint Warnung.

10.10 Berechtigungen

10.10.1 Marketing lesen: Kampagnen, Statistiken, Vorlagen, Segmente einsehen. 10.10.2 Marketing schreiben: Kampagnen erstellen, bearbeiten, versenden. 10.10.3 Marketing-Admin: Absender verwalten, Sperrliste verwalten, Tages-Limit konfigurieren, Spam-Override, Frequenz-Schutz setzen.

10.11 Phase 2 / bewusst NICHT in Phase 1

10.11.1 A/B-Tests automatisch (Gewinner-Versand an Rest). 10.11.2 Echte Mehrstufen-Sequenzen (Mail 1 → 3 Tage → Mail 2 → ...) im Marketing-Modul (Phase 1 über Automation-Engine machbar). 10.11.3 Erweiterte Analyse: Geräte-Aufschlüsselung, Geo-Map, Klick-Heat-Map. 10.11.4 Bedingter Inhalt (Block X nur wenn Feld Y = Z). 10.11.5 Drag-&-Drop-Email-Builder (Phase 1: Texteditor mit Vorlagen). 10.11.6 KI-optimierter Sende-Zeitpunkt pro Empfänger. 10.11.7 Granulare Abmelde-Kategorien (Newsletter, Aktion, Service-Update getrennt abmeldbar). 10.11.8 Re-Engagement-Kampagnen (Auto-Erkennung inaktiver Empfänger). 10.11.9 Aufwärm-Phase für neue Sende-Domains (Phase 2: Tag 1 = 100, Tag 7 = 1.000, Tag 30 = 10.000).

10.12 Klartext-Fehlertexte (Beispiele)

10.12.1 "Setup deiner Sende-Domain läuft noch. Wir prüfen alle 5 Minuten. [Status anzeigen]" 10.12.2 "Du brauchst eine verifizierte Sende-Domain bevor du Marketing-Mails versendest. [Domain einrichten]" 10.12.3 "Test-Mail an [Email] versendet. Falls nach 5 Min nicht angekommen: Spam-Ordner prüfen." 10.12.4 "Dein Segment liefert aktuell 0 Empfänger. Filter zu eng? [Segment editieren]" 10.12.5 "Tägliches Sende-Limit erreicht (10.000/10.000). Versand wird morgen 00:00 fortgesetzt." 10.12.6 "Versand fehlgeschlagen, Sender-Domain wurde widerrufen. Domain neu verifizieren und erneut starten." 10.12.7 "Im Footer fehlt die Absender-Adresse (DSGVO-Pflicht). [Footer ergänzen]" 10.12.8 "Nur 32% deiner Empfänger haben dokumentierte Einwilligung. Die anderen werden ausgeschlossen."

Modul 12: Telefonie [N16, 09.05.2026]

Was es tut: Bindet vorhandene Telefonie-Anbieter sauber an HiveGrid an. Aus jeder Kontakt-, Lead- oder Deal-Karte kann mit einem Klick angerufen werden. Eingehende Anrufe werden automatisch dem richtigen Kontakt zugeordnet, im Aktivitäts-Verlauf protokolliert, und nach dem Anruf kann der Mitarbeiter eine Notiz hinzufügen.

Phase-1-Anbieter: - AirCall (für Mandanten, die AirCall bereits einsetzen, z. B. Geerkens-Vertrieb) - HalloPetra (für SHK-Betriebe, die einen telefonischen Erst-Empfang über HalloPetra fahren, ca. 2.000 SHK-Nutzer in Deutschland, sehr etabliert in der Branche)

Optional gehalten (kein Anbieter-Pflicht-Setup): nicht jeder Mandant nutzt einen unterstützten Anbieter. Wer keinen Anbieter verbindet, sieht in HiveGrid die Click-to-Call-Funktion als normalen tel:-Link auf das Standard-Telefon des Geräts; eingehende Anrufe ohne Anbieter-Anbindung werden nicht protokolliert. Vorbild HubSpot, wo Telefonie ebenfalls Add-On ist, nicht Pflicht.

Löst ab: Nichts. AirCall und HalloPetra bleiben als externe Anbieter, HiveGrid bindet sauber an, statt eine eigene Telefonie zu bauen. Andere Anbieter (Sipgate, Auerswald-PBX, weitere) sind Phase 2.

Warum es wichtig ist: Telefon ist im SHK-Geschäft der Haupt-Kommunikationskanal mit Endkunden. Ohne automatisches Anruf-Logging wandert das Wissen "Wer hat wann mit wem worüber telefoniert" in Zettel, Excel-Listen und individuelle Köpfe, nicht ins CRM. HalloPetra-Anbindung in Phase 1 sorgt dafür, dass viele SHK-Betriebe am Tag eins sofort produktiven Mehrwert sehen.

12.1 Anbindung der Telefonie-Anbieter

12.1.1 Phase 1 unterstützte Anbieter: AirCall und HalloPetra. Pro Mandant kann genau einer der beiden verbunden sein, alternativ keiner (siehe Modul-Beschreibung oben). Sipgate, Auerswald, weitere sind Phase 2 (gleiche Architektur, anderer Adapter, siehe Modul 33a). 12.1.2 Pro Betrieb wird AirCall einmalig verbunden (Tenant-Admin oder Integrations-Admin meldet sich beim Setup mit dem AirCall-Account an, gewährt HiveGrid Zugriff). 12.1.3 Nach erfolgreicher Anmeldung listet HiveGrid alle AirCall-Mitarbeiter der Firma auf und schlägt automatisch eine Zuordnung zu HiveGrid-Mitarbeitern vor (basierend auf der Email-Adresse). Manuelle Korrektur möglich. 12.1.4 Klartext-Hinweis: "X von Y AirCall-Mitarbeitern automatisch zugeordnet. [Y] manuell zuordnen." 12.1.5 Funktion "Verbindung testen" prüft die Anbindung; bei Fehler erscheint spezifische Diagnose (Zugriff abgelaufen / Berechtigung fehlt / AirCall nicht erreichbar). 12.1.6 Die automatische Wieder-Anmeldung läuft im Hintergrund. Wird die Verbindung widerrufen, erscheint Klartext: "Deine AirCall-Verbindung wurde unterbrochen, bitte erneut verbinden. [Verbindung erneuern]". 12.1.7 HalloPetra-Anbindung (analog AirCall, eigener Adapter über Modul 33a) [N16, 09.05.2026]: - Anmeldung mit dem HalloPetra-Account einmalig pro Mandant. - Auto-Zuordnung der HalloPetra-Mitarbeiter zu HiveGrid-Mitarbeitern über Email-Adresse. - Eingehende Anrufe (auch verpasste) werden mit Anrufer-Nummer, Anruf-Datum, Mitschnitt-Link, ggf. HalloPetra-Notiz im HiveGrid-Aktivitäts-Verlauf protokolliert. - Click-to-Call ist über HalloPetra technisch möglich, soweit deren API es erlaubt; ansonsten Fallback auf tel:-Link. - HalloPetra-spezifische Funktionen (z. B. Sprach-Bot-Skripte, KI-Vorqualifikation) bleiben in HalloPetra. HiveGrid zeigt das Ergebnis (Anruf-Log, Vorqualifikations-Tags) als Lead/Aktivitäts-Eintrag. - Klartext bei Verbindungs-Verlust: „Deine HalloPetra-Verbindung wurde unterbrochen, bitte erneut verbinden. [Verbindung erneuern]".

12.2 Click-to-Call aus Kontakten

12.2.1 Aus jeder Kontakt-, Deal- und Lead-Detail-Ansicht erreichbare "Anrufen"-Funktion. 12.2.2 Hat der Kontakt mehrere Telefonnummern: Auswahl-Dialog (Standard-Nummer voreingestellt). Bei nur einer Nummer: direkter Anruf. 12.2.3 Nach Klick klingelt das AirCall-Gerät des Mitarbeiters (Web-App, Mobile-App oder Tisch-Telefon). Der Mitarbeiter nimmt in AirCall ab, AirCall ruft den Kontakt. 12.2.4 Der ausgehende Anruf wird automatisch protokolliert (siehe 12.5). 12.2.5 Telefonnummern werden beim Speichern automatisch normalisiert (z.B. 0211 1234567 wird zu +492111234567). Standard-Land ist Deutschland (anpassbar pro Betrieb). 12.2.6 Fallback ohne AirCall: ist AirCall nicht verbunden, zeigt die Anrufen-Funktion einen normalen tel:-Link, der das Standard-Telefon des Geräts/Browsers öffnet. Kein Logging in diesem Fall (außerhalb HiveGrid). 12.2.7 Klartext-Fehler: "Du bist keinem AirCall-User zugeordnet. [Admin kontaktieren]" / "Dieser Kontakt hat keine Telefonnummer. [Nummer hinzufügen]" / "AirCall meldet ['Quote überschritten']. [Erneut versuchen]".

12.3 Anruf-Aufzeichnung

12.3.1 Aufzeichnungen werden bei AirCall gespeichert (kein eigenes Re-Hosting in HiveGrid in Phase 1). 12.3.2 Liegt eine Aufzeichnung vor, erscheint im Anruf-Detail im HiveGrid ein Link "Aufzeichnung anhören (öffnet AirCall)". 12.3.3 Aufzeichnungen haben bei AirCall eine Aufbewahrungsfrist (abhängig vom AirCall-Tarif); HiveGrid zeigt im UI bis wann der Link verfügbar ist.

12.4 KI-Transkription

12.4.1 Phase 1: keine automatische Transkription. Aufzeichnung muss manuell in AirCall gehört werden. 12.4.2 Phase 2: automatische Transkription über EU-konformen Spracherkennungs-Dienst (Whisper-EU auf europäischer Infrastruktur). Das Transkript erscheint als Auto-Notiz am Anruf, durchsuchbar im CRM. 12.4.3 Phase 2 ergänzt: Auto-Klassifikation der Notiz und automatische Tags ("Wartungs-Anfrage", "Reklamation", "Termin-Vereinbarung").

12.5 Anruf-Verknüpfung mit Kontakten (Auto-Match)

12.5.1 Bei eingehendem Anruf normalisiert HiveGrid die Anrufer-Nummer und sucht in der Kontakt-Datenbank. 12.5.2 Exakter Treffer (Nummer stimmt komplett überein): Anruf wird dem Kontakt mit hoher Sicherheit zugeordnet. 12.5.3 Teilweise-Treffer (letzte 8 Ziffern stimmen): Vorschlag mit Klartext "Vermutlich [Kontakt-Name], manuell bestätigen?". 12.5.4 Kein Treffer zur Kontakt-Datenbank: Suche zusätzlich in Leads. Bleibt es bei keinem Treffer, ist die Anrufer-Nummer als "Unbekannte Nummer" sichtbar (mit Funktion "Als neuen Kontakt anlegen"). 12.5.5 Deal-Verknüpfung über Kontakt: ist der Anrufer ein Kontakt mit genau einem offenen Deal, wird der Anruf diesem Deal vorgeschlagen. 12.5.6 Manuelle Korrektur im Anruf-Detail jederzeit möglich (anderem Kontakt/Lead/Deal/Projekt zuordnen). 12.5.7 Push-Benachrichtigung an den zugewiesenen Mitarbeiter beim eingehenden Anruf: "Eingehender Anruf von [Name oder Nummer]. [Kontakt öffnen]", Mitarbeiter kann Notizen vorbereiten, während der Anruf läuft. 12.5.8 Verpasste Anrufe werden als solche markiert (Notification an Mitarbeiter mit Berechtigung) und mit Funktion "Rückruf-Aufgabe anlegen".

12.6 Notizen nach dem Anruf

12.6.1 Direkt nach Anruf-Ende erscheint Hinweis: "Anruf beendet (3:45 Min), Notiz hinzufügen?". 12.6.2 Editor: einfacher Text mit Formatierungs-Möglichkeiten, Speichern. 12.6.3 Notizen werden im Aktivitäts-Verlauf des verknüpften Kontakts/Deals sichtbar. 12.6.4 Editierbar: Phase 1 jederzeit (mit Audit-Eintrag bei Änderung). Phase 2: nach 30 Tagen Read-only (anpassbar).

12.7 Anruf-Liste am Kontakt

12.7.1 Im Kontakt-Detail erscheint im Aktivitäts-Verlauf jeder Anruf mit Klartext: "Eingehender Anruf von Max Mustermann (3:45 Min)" / "Verpasster Anruf von +49..." / "Ausgehender Anruf von [Mitarbeiter] (5:12 Min)". 12.7.2 Aggregat-Statistik im Kontakt-Detail: "12 Anrufe geführt (8 ausgehend, 4 eingehend), Durchschnitt 4:23 Min". 12.7.3 Klick auf den Eintrag öffnet das Anruf-Detail (Notiz, Aufzeichnungs-Link, Tags).

12.8 Trigger für die Automation-Engine

12.8.1 Modul 17 kann auf Anruf-Ereignisse reagieren: Anruf eingegangen, Anruf angenommen, Anruf beendet, Anruf verpasst. 12.8.2 Beispiele für Geerkens: "Wenn Anruf > 2 Min mit unbekannter Nummer → Lead anlegen" / "Wenn verpasster Anruf während Bürozeit → Aufgabe für Backoffice 'Rückruf'" / "Wenn Anruf-Tag = 'Wartung' → Deal in Pipeline 'Service' anlegen". 12.8.3 Filter-Bedingungen pro Trigger (Richtung, Dauer, Kontakt-vorhanden).

12.9 Berechtigungen

12.9.1 Click-to-Call: der Mitarbeiter kann selbst anrufen. 12.9.2 Eigene Anrufe sehen: der Mitarbeiter sieht nur seine eigenen Anrufe. 12.9.3 Alle Anrufe sehen: Vorgesetzte sehen alle Anrufe im Betrieb. 12.9.4 Notizen schreiben (eigene / alle). 12.9.5 Telefonie-Admin: Verbindung einrichten, Mitarbeiter-Zuordnungen verwalten, Trigger konfigurieren.

12.10 Phase 2 / bewusst NICHT in Phase 1

12.10.1 Sipgate-Anbindung als zweiter Anbieter. 12.10.2 Anruf-Aufzeichnungs-Transkription über Whisper-EU. 12.10.3 Telefonieren direkt aus dem HiveGrid-Browser ohne externe AirCall-App. 12.10.4 Massen-Anrufe / Power-Dialer (Listen abarbeiten). 12.10.5 Anruf-Skripte / Vertriebsleitfaden im Click-to-Call-Kontext. 12.10.6 KI-Auto-Tags basierend auf Anruf-Notiz. 12.10.7 Reporting-Dashboard (Anruf-Volumen pro Team, Conversion-Rate).

12.11 Klartext-Fehlertexte (Beispiele)

12.11.1 "Deine AirCall-Verbindung wurde unterbrochen. [Erneut verbinden]" 12.11.2 "AirCall meldet 'Zugriff verweigert', möglicherweise wurde dein AirCall-Account aus der Company entfernt." 12.11.3 "Du bist keinem AirCall-User zugeordnet. [Admin kontaktieren]" 12.11.4 "Dieser Kontakt hat keine Telefonnummer hinterlegt. [Nummer hinzufügen]" 12.11.5 "Die Nummer [wert] konnte nicht angewählt werden. [Korrigieren]" 12.11.6 "AirCall ist nicht verbunden. [Tenant-Admin: Verbindung einrichten]"

Modul 13: Team-Chat

Was es tut: Interner Team-Chat in Echtzeit, der Slack/Teams/Quiply für die interne Kommunikation innerhalb von HiveGrid ablöst. Drei Ebenen: automatische Projekt-Channels (pro Projekt entsteht ein eigener Chat-Raum), Gruppen-Channels (Team-Süd, Außendienst, Lehrlinge, Notfall-Pikett), und Direkt-Nachrichten zwischen zwei Mitarbeitern. Nachrichten können auf Themen verzweigen (Threads), bekommen Reaktionen (Emojis), wichtige Nachrichten werden angeheftet, Dateien und Fotos werden direkt im Chat ausgetauscht und können mit einem Klick zu einer Aufgabe gemacht werden.

Löst ab: Quiply (Mitarbeiter-Chat) und teilweise Slack/Teams für die interne Kommunikation. Wichtige Klarstellung: Dies ist kein Slack-Konkurrent für die breite Welt, sondern eine Projekt-Kommunikations-Schicht direkt in HiveGrid. Das Ziel ist, dass Mitarbeiter HiveGrid nicht verlassen müssen, um über Projekte zu reden.

Warum es wichtig ist: Heute läuft die interne Kommunikation bei Geerkens über WhatsApp-Gruppen, Quiply und Excel-Listen. Wissen verschwindet in Privat-Chats und ist für neue Mitarbeiter nicht auffindbar. Mit Projekt-Chats wird jede Konversation zum Projekt automatisch dokumentiert.

13.1 Drei Ebenen (Projekt-Channel, Gruppe, Direktnachricht)

13.1.1 Projekt-Channel (Projekt): Wird bei jeder Projekt-Anlage automatisch erzeugt. Der Channel-Name ist der Projekt-Titel. Default-Mitglieder sind alle Projekt-Mitarbeiter inklusive Projektleiter. System-Nachricht zur Anlage: "Projekt angelegt von [Mitarbeiter] am [Datum]. PL: [Name]. Mitglieder: [Liste]". 13.1.2 Bei Mitarbeiter-Wechsel im Projekt wird der Channel automatisch synchronisiert (Hinzufügen/Entfernen mit System-Nachricht). 13.1.3 Bei Projekt-Abschluss oder -Stornierung wird der Channel 7 Tage später automatisch archiviert (anpassbar pro Pipeline). Read-only, bisherige Nachrichten bleiben lesbar. 13.1.4 Bei Projekt-Reaktivierung wird der Channel ebenfalls wieder aktiviert. 13.1.5 Pro Projekt maximal ein aktiver Projekt-Chat (kein Doppel-Anlage). 13.1.6 Gruppen-Channel: manuell angelegt durch Mitarbeiter mit Berechtigung. Beispiele: "Team Süd", "Außendienst-Allgemein", "Lehrlinge", "Notfall-Pikett". Optional privat (nur Mitglieder sehen) oder öffentlich (im Channel-Browser sichtbar, jeder kann beitreten). 13.1.7 Mitglieder-Verwaltung durch Channel-Admins; einzelne Mitglieder können verlassen (außer der letzte Admin, Klartext-Block: "Du bist der einzige Admin. Bitte einen anderen Mitarbeiter zum Admin ernennen oder den Channel archivieren, bevor du gehst"). 13.1.8 Direkt-Nachricht (DM): Zwei-Personen-Chat. Anlage über User-Auswahl. Existiert bereits ein DM zwischen den beiden, wird er wiederverwendet (kein Duplikat). Lese-Bestätigungen sofort sichtbar pro Nachricht. 13.1.9 Gruppen-DMs (3+ Personen) sind Phase 2. In Phase 1 wird ein Gruppen-Channel angelegt. 13.1.10 Tenant-Admins sehen Direkt-Nachrichten anderer Mitarbeiter nicht standardmäßig. Nur bei explizitem Audit-Antrag mit Pflicht-Begründung (geloggt im Audit-Trail), z.B. bei Compliance-Anfragen.

13.2 Reactions, Threads, Pinned

13.2.1 Reaktionen (Emojis): Per Klick auf eine Nachricht öffnet sich der Emoji-Picker. Andere sehen die Reaktion sofort. Klick auf eigene Reaktion entfernt sie. Maximal 20 verschiedene Emojis pro Nachricht (Anti-Spam), maximal 8 eigene Reaktionen pro Nachricht. 13.2.2 Threads (Themen-Verzweigung): Auf jede Nachricht kann "Im Thread antworten" geklickt werden. Der Thread öffnet sich als Seiten-Bereich oder eigene Ansicht und enthält die Eltern-Nachricht und alle Antworten chronologisch. Im Haupt-Verlauf zeigt die Eltern-Nachricht einen Indikator: "X Antworten, letzte Antwort vor [Zeit]". 13.2.3 Thread-Antworten erscheinen standardmäßig nicht im Haupt-Verlauf (Slack-Pattern). Optionaler Toggle "Auch im Hauptverlauf zeigen". 13.2.4 Thread-Benachrichtigungen gehen nur an Thread-Teilnehmer und bei expliziter Erwähnung. 13.2.5 Angeheftete Nachrichten (Pinned): Wichtige Nachrichten werden an den Channel angeheftet (Adressen, Material-Listen, Notrufnummern, Zugangsdaten Baustelle). Maximal 50 Pins pro Channel. Pinnen erfordert Channel-Admin-Status oder eigene Nachricht des Verfassers.

13.3 Erwähnungen (Mentions)

13.3.1 Tipp-Trigger ist @. Auto-Vervollständigung schlägt vor: Mitarbeiter (im Channel + im Betrieb), Projekte, Deals, Kontakte, Firmen. 13.3.2 Erwähnung eines Mitarbeiters erzeugt eine sofortige Benachrichtigung an ihn (auch wenn der Channel auf "stumm" steht, DMs und Erwähnungen kommen immer durch). 13.3.3 Erwähnung eines Projekts/Deals/Kontakts/Firma wird zu einem klickbaren Chip. Klick navigiert zur Detail-Ansicht. Zusätzlich entsteht im Aktivitäts-Verlauf der erwähnten Entität ein Eintrag: "[Mitarbeiter] hat im Chat [Channel-Name] über dich gesprochen: [Snippet]". 13.3.4 Spezial-Erwähnungen: @channel benachrichtigt alle Mitglieder, @here nur die aktuell online sind. Bei Channels mit mehr als 25 Mitgliedern erscheint eine Bestätigungs-Frage: "Damit benachrichtigst du 47 Personen. Trotzdem?". 13.3.5 Berechtigungs-bewusst: nicht-sichtbare Entitäten erscheinen nicht in der Auto-Vervollständigung.

13.4 Datei-Anhänge

13.4.1 Datei-Upload aus dem Schreib-Bereich (Drag-&-Drop oder Datei-Auswahl). Mehrfach-Upload möglich. 13.4.2 Bilder werden inline als Vorschau angezeigt (Klick öffnet Vollbild-Ansicht). Videos zeigen Vorschau mit Abspiel-Schaltfläche. PDFs/Office-Dateien als Karte mit Vorschau-Link. Andere Dateitypen mit allgemeinem Datei-Symbol. 13.4.3 In Projekt-Channels werden hochgeladene Dateien automatisch zusätzlich in der Projekt-Datei-Übersicht (Modul 4 / 23) abgelegt, sie tauchen also auch im Datei-Tab des Projekts auf. 13.4.4 In Gruppen- und DM-Channels gibt es eine Funktion "In Projekt-Dateien speichern", die die Datei in einen wählbaren Projekt-Datei-Bereich kopiert. 13.4.5 Dateigrößen- und Typ-Limits werden zentral in Modul 23 (Dateien) konfiguriert. 13.4.6 Foto-Direkt-Aufnahme auf dem Mobiltelefon: Kamera öffnen, Foto machen, mit einem Tippen senden. Optional: Datum/Uhrzeit/GPS-Koordinaten als Auto-Bildunterschrift (Default aus, GPS nur mit Mitarbeiter-Erlaubnis). 13.4.7 Sprach-Notizen auf dem Mobiltelefon: Aufnahme-Schaltfläche gedrückt halten, loslassen sendet. Audio als Anhang. Phase 2 ergänzt automatisches Transkript (Whisper-EU).

13.5 Echtzeit-Verbindung und Lese-Bestätigungen

13.5.1 Nachrichten erscheinen bei allen Mitgliedern in Echtzeit (Echtzeit-Verbindung im Hintergrund). 13.5.2 Lese-Bestätigungen: Bei DMs sichtbar "gelesen um [Zeit]". Bei Gruppen/Projekt-Chats Aggregat "X von Y gelesen" (Klick zeigt Liste der Gelesen-/Ungelesen-Personen). 13.5.3 Tipp-Indikator: "Max tippt..." erscheint, während ein anderer Mitarbeiter schreibt. 13.5.4 Anwesenheitsstatus: Online / Abwesend (5 Min ohne Aktivität) / Offline. Sichtbar in Mitglieder-Listen. 13.5.5 Verbindungs-Verlust: Banner "Verbindung unterbrochen, versuche Neuaufbau...". Bei erfolgreicher Wiederherstellung: kurzer Hinweis "Wieder verbunden", verpasste Nachrichten werden nachgeladen.

13.6 Übersicht und Suche

13.6.1 Sidebar-Punkt "Chat" mit Ungelesen-Zähler über alle eigenen Channels. 13.6.2 Channel-Übersicht zeigt pro Channel: Name, letzte Nachricht (gekürzt), Zeitstempel, Ungelesen-Zähler, Erwähnungs-Indikator (separat hervorgehoben), Anpinnen-Marker, Stumm-Marker. 13.6.3 Default-Sortierung: Letzte Nachricht oben, angepinnte Channels ganz oben. 13.6.4 Filter: Channel-Typ (Projekt/Gruppe/DM), nur ungelesene, nur mit Erwähnungen, Projekt-Status, Tag. 13.6.5 Cross-Channel-Suche durchsucht alle eigenen Channels (Volltext über Nachrichten und Channel-Namen). 13.6.6 Eigener Bereich "Meine Erwähnungen" listet alle aktiven @-Erwähnungen auf den Mitarbeiter über alle Channels. 13.6.7 Channel-Browser zeigt öffentliche Gruppen-Channels zum Beitreten.

13.7 Bearbeiten und Löschen

13.7.1 Eigene Nachrichten können innerhalb von 24 Stunden nach Versand editiert werden. Editiert-Marker erscheint. Nach 24h ist Editieren gesperrt (außer Tenant-Admin). 13.7.2 Eigene Nachrichten können vom Verfasser, Channel-Admin oder Tenant-Admin gelöscht werden. Im Verlauf bleibt ein Lösch-Platzhalter "Nachricht gelöscht".

13.8 Aufgabe aus Nachricht erstellen ("Mark as Task")

13.8.1 Pro Nachricht erreichbare Funktion "Aus Nachricht Aufgabe erstellen". 13.8.2 Öffnet ein Aufgabe-Anlage-Fenster mit voreingestelltem Titel (erste Zeile / 80 Zeichen) und Beschreibung (kompletter Nachrichten-Text). 13.8.3 Bei Projekt-Channel: Aufgabe wird automatisch dem Projekt zugeordnet. 13.8.4 Nach Bestätigung erscheint unter der Quell-Nachricht eine System-Antwort: "[Mitarbeiter] hat aus dieser Nachricht eine Aufgabe erstellt: [Titel] → [Link]". 13.8.5 Erfordert Aufgaben-Schreib-Berechtigung (Modul 26).

13.9 Mobile-First für Monteure (LP-2)

13.9.1 Monteur-Smartphone-Bedienung mit Handschuhen optimiert: Schreib-Bereich prominent in der Daumen-Zone. 13.9.2 Ein-Tipp-"Foto senden" (öffnet Kamera direkt). 13.9.3 Sprach-Notiz-Funktion (gedrückt halten, loslassen sendet). 13.9.4 Reduzierte Channel-Übersicht: Default-Filter "Aktive Projekt-Chats + DMs mit Erwähnungen". 13.9.5 Vereinfachte Threads (linear statt Seiten-Bereich). 13.9.6 Push-Benachrichtigungen mit Schnell-Antwort-Funktion (direkt aus der Benachrichtigung schreiben, Phase 2 nativ, Phase 1 öffnet Channel). 13.9.7 Benachrichtigungs-Inhalt enthält nur: Channel-Name, Absender-Vorname, max. 100 Zeichen Vorschau. Keine Adressen, keine Kunden-Details (Datenschutz auf dem Sperrbildschirm). 13.9.8 Tenant-Einstellung "Push-Vorschau im Sperrbildschirm" (Default an, Aus = nur "Neue Nachricht").

13.10 Berechtigungen

13.10.1 Eigene Channels lesen: der Mitarbeiter sieht Channels, in denen er Mitglied ist. 13.10.2 Schreiben: der Mitarbeiter kann Nachrichten senden, reagieren, Threads, Datei-Uploads, Aufgaben aus Nachrichten erstellen. 13.10.3 Channels anlegen: Gruppen-Channels erstellen. 13.10.4 DMs starten. 13.10.5 Chat-Admin: globale Admin-Rechte über alle Channels (Force-Edit, Force-Archive, Force-Delete). 13.10.6 Alle Channels lesen (Audit): Tenant-Admin-Sicht für Compliance-Zwecke. Jeder Lese-Zugriff wird audit-geloggt mit Pflicht-Begründung.

13.11 Phase 2 / bewusst NICHT in Phase 1

13.11.1 Gruppen-DMs mit 3+ Personen ohne Channel-Anlage. 13.11.2 Eigene Emoji-Codes pro Betrieb (in Phase 1 nur Standard-Emojis). 13.11.3 Tägliche Email-Zusammenfassung verpasster Erwähnungen. 13.11.4 Sprach-/Video-Anrufe direkt im Chat. 13.11.5 Slack-/Teams-Brücke. 13.11.6 Bots / Slash-Befehle (/befehl). 13.11.7 Ende-zu-Ende-Verschlüsselung (Phase 1: serverseitige Verschlüsselung im Ruhezustand). 13.11.8 Erweiterte Suche (nach Verfasser, Datum, Erwähnungs-Typ). 13.11.9 "Später senden" für Nachrichten. 13.11.10 Drag-Reorder von angepinnten Nachrichten. 13.11.11 KI-Auto-Übersetzung (DE↔PL/EN/UA für mehrsprachige Teams, PL-Monteur schreibt PL, Büro liest DE). 13.11.12 KI-Tageszusammenfassung "Was war heute wichtig?". 13.11.13 KI-Schnell-Antwort-Vorschläge. 13.11.14 Sprach-Notiz-Volltextsuche im Transkript. 13.11.15 Native iOS/Android-Apps (Phase 1: PWA mit Web-Push). 13.11.16 Native Schnell-Antwort aus Push-Benachrichtigung.

13.12 Klartext-Fehlertexte (Beispiele)

13.12.1 "Du bist noch in keinem Channel. Lege einen neuen an oder warte auf eine Einladung." 13.12.2 "Noch keine Nachrichten. Schreib die erste!" 13.12.3 "Du bist kein Mitglied dieses Channels." 13.12.4 "Dieser Channel ist archiviert. Du kannst lesen, aber nicht mehr schreiben. [Reaktivieren]" 13.12.5 "Verbindung unterbrochen, versuche Neuaufbau..." 13.12.6 "Damit benachrichtigst du 47 Personen. Trotzdem?" 13.12.7 "Editieren ist nur innerhalb 24 Stunden möglich." 13.12.8 "Datei [Name] ist zu groß ([X] MB von max. [Y] MB)." 13.12.9 "Dateityp [.exe] ist nicht erlaubt." 13.12.10 "Du bist der einzige Admin in diesem Channel. Bitte einen anderen Mitarbeiter zum Admin ernennen, bevor du gehst." 13.12.11 "Browser-Benachrichtigungen sind deaktiviert. In den Browser-Einstellungen aktivieren um wichtige Erwähnungen zu erhalten."

Modul 22: Notifications

Was es tut: Drei-Kanal-Benachrichtigungs-System: Push aufs Mobiltelefon, Email und In-App-Glocke (Notification-Center). Pro Mitarbeiter pro Ereignis-Typ einstellbar (welche Kanäle, welche Priorität). Eigene Ruhezeiten (z.B. 22:00–07:00 keine Push). Anti-Spam-Bündelung (statt 23 Einzel-Pushes "23 neue Leads").

Löst ab: Notification-Funktionen aus HubSpot, Quiply, Slack, vereinheitlicht in einer zentralen Stelle.

Warum es wichtig ist: Ohne klare Benachrichtigungs-Strategie wird HiveGrid zur Lärm-Quelle (Mitarbeiter werden 100x am Tag gepiept und schalten alles aus). Mit Pro-Mitarbeiter-Einstellungen und Bündelung bleibt das System nützlich.

22.1 Kanäle (Push, Email, In-App)

22.1.1 In-App (Glocke): Glocken-Symbol in der Kopfzeile mit Ungelesen-Zähler. Klick öffnet das Notification-Center mit allen Benachrichtigungen. Default-Kanal, der für jede Benachrichtigung aktiv ist und nicht deaktiviert werden kann (er ist "die Wahrheit"). Aktualisierung in Echtzeit. 22.1.2 Email: Versand über die in Modul 9 verifizierte Sende-Domain mit Betriebs-Branding (Logo, Hauptfarbe). Pro gebündeltes Ereignis eine Email mit zusammengefasstem Inhalt. Standard-Footer "Du bekommst diese Email weil [...], [Benachrichtigungs-Einstellungen]". 22.1.3 Mobile-Push: Push aufs Smartphone (iPhone via Apple-Push, Android via Google-Push) über die HiveGrid-Mobile-App. Push-Inhalt enthält Kurz-Titel, Beschreibung, Vertiefungs-Link und (wenn gebündelt) Anzahl. Apple-konformer Berechtigungs-Ablauf: Ersteinsatz-Erklärungs-Screen "Warum brauchen wir Push?", danach Standard-Berechtigungs-Dialog. 22.1.4 Bei verweigerter Push-Berechtigung erscheint Klartext im Einstellungs-Bereich: "Push ist auf diesem Gerät deaktiviert. [Geräte-Einstellungen öffnen]".

22.2 Anti-Spam-Bündelung (kritisch: verhindert Notification-Storm)

22.2.1 Grundregel: Mehrere gleichartige Benachrichtigungen an denselben Mitarbeiter innerhalb von 5 Minuten werden zu einer Sammel-Benachrichtigung gebündelt. Beispiel: Statt 23 einzelner Pushes "Neuer Lead" kommt eine Push: "23 neue Leads in den letzten 5 Min, [Lead-Inbox öffnen]". 22.2.2 Im Notification-Center: alle Einzel-Benachrichtigungen bleiben einzeln sichtbar (Wahrheit), aber der Echtzeit-Hinweis (Toast/Badge) erscheint nur einmal. 22.2.3 Bei Email: eine Sammel-Email pro Bündel, nicht 23 einzelne. 22.2.4 Bündel-Fenster ist gleitend: Bei jedem neuen Ereignis innerhalb von 5 Min wird der Zähler erhöht. Nach 5 Min ohne neues Ereignis wird das Bündel geschlossen und (falls Push noch nicht raus war) versendet. 22.2.5 Maximale Bündel-Größe: 100 Ereignisse, danach wird ein neues Bündel begonnen. 22.2.6 Beispiele für Bündelung: - 23 neue Leads in 4 Min → 1 Push: "23 neue Leads in den letzten 5 Minuten" - 7 Aufgaben in 5 Min an Monteur zugewiesen → 1 Push: "7 neue Aufgaben" - 50 Chat-Nachrichten in 5 Min im Projekt-Channel → 1 Push: "50 neue Nachrichten in 'Müller Heizung'" 22.2.7 Bündelungs-Ausnahmen: Dringende Benachrichtigungen (urgent-Priorität) werden nie gebündelt, sofortiger Versand. Direkt-Erwähnungen im Chat (@user) werden nie mit anderen Erwähnungen gebündelt. Sicherheits-Benachrichtigungen (Login von neuem Gerät, Passwort geändert, 2FA deaktiviert) werden nie gebündelt. 22.2.8 Pro-Mitarbeiter-Limit: maximal 10 Pushes pro Stunde (Rest gebündelt), verhindert auch bei kaputten Automationen einen Push-Sturm aufs Smartphone. 22.2.9 Tenant-Admin-Konfiguration des Bündel-Fensters pro Ereignis-Gruppe ist Phase 2.

22.3 Ruhezeiten

22.3.1 Pro Mitarbeiter konfigurierbar: Wochentag(e), Start-Zeit, End-Zeit, optional "Auch dringende Benachrichtigungen zurückhalten" (Default aus, dringende kommen durch). 22.3.2 Schnell-Auswahl: "Werktags", "Wochenende", "Täglich". Mehrere Ruhezeiten parallel möglich. 22.3.3 Ein Master-Schalter "Ruhezeiten aktiv" für Urlaub-Aussetzen. 22.3.4 Default-Ruhezeit beim Onboarding für Mobile-Push: täglich 22:00–07:00 + Wochenende ganztägig, dringende Benachrichtigungen kommen trotzdem durch. 22.3.5 Wirkung: Während Ruhezeit eingehende Benachrichtigungen werden: - In-App: sofort sichtbar im Center (kein Pop-up, kein Sound) - Email + Push: gepuffert bis Ruhezeit-Ende, dann mit aktualisiertem Bündel-Zähler versendet 22.3.6 Override-Hierarchie (höchste Priorität zuerst): Channel-Stumm → Ruhezeit → Mitarbeiter-Standard → Channel-Standard.

22.4 Notification-Center

22.4.1 Listen-Anzeige aller Benachrichtigungen (Drawer oder Seite) mit pro Eintrag: Titel, kurzer Beschreibungs-Text, Datum/Zeit, Auslöser (Avatar oder System-Marker), Vertiefungs-Indikator, Lese-Status, Priorität, bei Bündel "X Ereignisse, [Alle anzeigen]". 22.4.2 Tabs/Filter: Alle / Ungelesen / Markiert. Filter nach Ereignis-Typ, Auslöser, Zeitraum, Priorität. Suche über Titel + Beschreibung. 22.4.3 Aktionen pro Eintrag: Als gelesen / ungelesen markieren, Wegklicken, Klick öffnet Vertiefungs-Link (markiert automatisch als gelesen). Bündel-Eintrag "Alle anzeigen" expandiert. 22.4.4 Bulk-Aktionen: Alle markieren, alle gelesen, mehrere wegklicken. Bei mehr als 50 ungelesenen Bestätigungs-Frage: "124 Benachrichtigungen als gelesen markieren? [Bestätigen] [Abbrechen]". 22.4.5 Alter-Filter: Default zeigt 90 Tage. Älter wird ausgeblendet (Auto-Hard-Lösch ist Phase 2).

22.5 Abo-Verwaltung pro Nutzer

22.5.1 Pro Mitarbeiter Übersicht aller Ereignis-Typen, gruppiert nach Modul (CRM, Leads, Projekte, Aufgaben, Termine, Chat, ...). 22.5.2 Pro Ereignis-Typ: Schalter pro Kanal (In-App, Email, Push) und Prioritäts-Schwelle (Alle / Normal+ / Hoch+ / Nur dringend). 22.5.3 Master-Schalter "Alle Email aus" mit Klartext: "Du erhältst keine Email-Benachrichtigungen mehr, auch nicht für neue Ereignis-Typen, die wir später hinzufügen. Wichtige Sicherheits-Mails (Login, Passwort) bleiben immer aktiv." 22.5.4 Funktion "Auf Standard für meine Rolle zurücksetzen". 22.5.5 Standard-Sets pro Rolle beim Onboarding: - Vertriebler: In-App + Push für Lead-/Deal-Ereignisse - Projektleiter: In-App + Push für Projekt-/Aufgaben-Ereignisse, Email für Termin-Erinnerungen - Monteur: In-App + Push für Aufgaben-Zuweisungen, Plantafel-Änderungen, Abnahme-Anfragen; Email aus - Büro/Backoffice: alle Kanäle für Eingang-Ereignisse (Lead, Mail, Formular) - GF: tägliche Email-Zusammenfassung (Phase 2), Push für Eskalationen - Marketing: Email für Kampagnen-Status, In-App für Lead-Ereignisse 22.5.6 Standards sind als deklarative Branchen-Vorlagen austauschbar (LP-3).

22.6 Mobile-Geräte-Verwaltung

22.6.1 Übersicht aller registrierten Mobile-Geräte des Mitarbeiters (iPhone-X, Samsung-Y) mit Status (aktiv / inaktiv > 30 Tage / abgemeldet). 22.6.2 Pro Gerät: Test-Push senden, Umbenennen, Abmelden. 22.6.3 Bei keinem Gerät: "Noch kein Mobile-Gerät verbunden, installiere die HiveGrid-App und logge dich ein, um Push zu erhalten. [App-Store-Link]". 22.6.4 Auto-Abmelde bei: Push-Versand-Fehler "Token ungültig", Mitarbeiter-Logout, Mitarbeiter-Deaktivierung. 22.6.5 Tenant-Admin sieht nicht die Geräte anderer Mitarbeiter (Privatsphäre).

22.7 Was kann eine Benachrichtigung auslösen (Auszug)

22.7.1 Lead: angelegt, mir zugewiesen, Antwort erhalten, als Spam markiert, Quell-Anomalie. 22.7.2 Deal: mir zugewiesen, Stufenwechsel, gewonnen, verloren, Eskalation bei Stillstand. 22.7.3 Projekt/Aufgabe: mir zugewiesen, Stufenwechsel, Abnahme-Anfrage, Aufgabe fällig, Aufgabe überfällig. 22.7.4 Termin: geplant, 24h-Erinnerung, 1h-Erinnerung, abgesagt, verschoben. 22.7.5 Chat: Direkt-Erwähnung, DM erhalten, Thread-Antwort. 22.7.6 Email/Anruf: persönliche Mail erhalten, Mail-Bounce, verpasster Anruf, Sprach-Nachricht. 22.7.7 Automation: Ausführung fehlgeschlagen, Vorschau-Lauf abgeschlossen, Limit erreicht. 22.7.8 Sicherheit: Login von neuem Gerät (hoch), Passwort geändert (hoch), 2FA deaktiviert (dringend), diese sind nie deaktivierbar und nie gebündelt. 22.7.9 Customer-Portal: Endkunde hat kommentiert / freigegeben / Datei hochgeladen. 22.7.10 Integrations: KWP-Synchronisation fehlgeschlagen, KWP-Schema-Abweichung erkannt. 22.7.11 Abrechnung: Tenant eingefroren, Zahlung fehlgeschlagen, Audit-Export fertig.

22.8 Versand-Pipeline (knapp)

22.8.1 Bei Versand-Fehler werden transiente Fehler bis zu 3-mal mit Pause wiederholt (SMTP-Timeout, Push-Server-Überlast). Permanente Fehler (Token ungültig, Adresse nicht existent) werden nicht wiederholt. 22.8.2 Bei wiederholtem Email-Bounce eines Mitarbeiters wird der Email-Kanal für ihn 7 Tage pausiert mit Klartext im Notification-Center: "Emails an dich kommen aktuell nicht an, bitte Email-Adresse prüfen". 22.8.3 EU-Versand (LP-13): SMTP über EU-Provider, Push über EU-gehosteten Vermittler (Apple/Google sind die letzten Endpunkte und nicht vermeidbar, Push-Inhalt enthält aber keine sensiblen Personen-Daten).

22.9 Berechtigungen

22.9.1 Self-Scope ist Standard: jeder Mitarbeiter sieht und verwaltet nur eigene Benachrichtigungen, Einstellungen und Geräte. 22.9.2 Notification-Admin: Email-Vorlagen ansehen, Test-Benachrichtigungen senden, in Phase 2 Bündel-Einstellungen ändern.

22.10 Phase 2 / bewusst NICHT in Phase 1

22.10.1 Tägliche Email-Zusammenfassung (statt Einzel-Mails). 22.10.2 Schlummern-Funktion (Benachrichtigung in X Stunden wieder im Center). 22.10.3 WhatsApp als 4. Kanal. 22.10.4 Tenant-Admin-konfigurierbare Bündel-Fenster. 22.10.5 Tenant-Admin-konfigurierbare Email-Vorlagen. 22.10.6 Zeitfenster-Regeln ("Lead-Benachrichtigungen nur Mo-Fr 8-18"). 22.10.7 Cross-Geräte-Lesen-Sync (Mark-as-read auf Desktop schließt Push-Banner auf Mobile). 22.10.8 Anomalie-Auto-Pause (KI erkennt Notification-Storms). 22.10.9 Custom-Sounds pro Priorität. 22.10.10 Anpinnen wichtiger Benachrichtigungen im Center. 22.10.11 Auto-Aufräumen alter Benachrichtigungen (>90 Tage hart löschen). 22.10.12 Web-Push als 4. Kanal (für Mitarbeiter ohne Mobile-App).

22.11 Klartext-Fehlertexte (Beispiele)

22.11.1 "Keine Benachrichtigungen, sobald etwas Wichtiges passiert, erscheint es hier." 22.11.2 "Emails an dich kommen aktuell nicht an, bitte Email-Adresse prüfen. [Profil]" 22.11.3 "Push ist auf diesem Gerät deaktiviert. [Geräte-Einstellungen]" 22.11.4 "Du bekommst keine Email-Benachrichtigungen mehr (außer Sicherheit). [Wieder aktivieren]" 22.11.5 "Diese Ruhezeit überschneidet sich mit '[X]', Vereinigung der Fenster aktiv." 22.11.6 "Push-Test fehlgeschlagen, möglicherweise wurden Push-Berechtigungen am Gerät widerrufen." 22.11.7 "Benachrichtigungs-Versand zeigt ungewöhnliches Aufkommen (5x normal). Bitte Automationen prüfen, möglicherweise Loop. [Automation-Studio]"

Modul 25: Calendar-Sync

Was es tut: Bidirektionale Synchronisation zwischen HiveGrid-Terminen (Booking, Projekt-Termine, Plantafel-Einträge) und externen Kalendern (Google Calendar, Microsoft Outlook). Termine, die im HiveGrid entstehen, erscheinen automatisch im Google-/Outlook-Kalender des Mitarbeiters. Externe Termine (private Termine, andere Meetings) kommen umgekehrt nur als "belegt" ins HiveGrid, damit das Booking-Modul keine Doppel-Buchungen anbietet. Die Anbindung erfolgt pro Mitarbeiter (jeder verbindet seinen eigenen Kalender), nicht pro Betrieb.

Löst ab: Standalone-Nutzung von Google Calendar bei Geerkens (teilweise, Geerkens behält Google Workspace, aber HiveGrid wird die Termin-Wahrheit).

Warum es wichtig ist: Ohne Kalender-Sync sind Mitarbeiter gezwungen, Termine in beiden Systemen zu pflegen, was in der Praxis dazu führt, dass nur einer aktuell ist. Doppelt-Eintragungen, Doppel-Buchungen und verpasste Termine sind die Folge.

25.1 Bidirektional Google + Microsoft (Pflicht in Phase 1)

25.1.1 Phase 1 unterstützt Google Calendar (inkl. Google Workspace) und Microsoft Outlook / Microsoft 365 Calendar. Beide voll bidirektional. 25.1.2 Bidirektional ist Phase-1-Pflicht (nicht Phase 2): HiveGrid → extern UND extern → HiveGrid sind beide ab Tag 1 verfügbar. 25.1.3 Der Mitarbeiter kann pro Anbieter eine Verbindung haben (z.B. Google + Microsoft parallel, falls geschäftlich Outlook und privat Gmail). Ein interner HiveGrid-Termin wird dann in beide externe Kalender gespiegelt. 25.1.4 Phase 2: Apple/iCloud-Calendar, FastMail, iCal-Feed (read-only).

25.2 OAuth pro Nutzer (jeder verbindet selbst)

25.2.1 Verbindung wird pro Mitarbeiter in Einstellungen → Integrationen → Kalender aufgebaut. Keine Tenant-zentrale Verbindung in Phase 1. 25.2.2 Mitarbeiter klickt "Google Calendar verbinden" / "Outlook verbinden" → offizielles Anbieter-Login-Fenster → erteilt HiveGrid Zugriff auf die Kalender. 25.2.3 Notwendige Berechtigungen: Lesen und Schreiben von Kalender-Events, Email + Profil zur Identifikation. 25.2.4 Nach erfolgreicher Verbindung listet HiveGrid alle verfügbaren externen Kalender (Primary, weitere) auf und fragt, welche synchronisiert werden sollen. Standard: Haupt-Kalender. 25.2.5 Bei Microsoft mit IT-Admin-gesperrtem Tenant erscheint Klartext: "Dein IT-Admin muss diese Verbindung zuerst genehmigen. [Admin-Genehmigungs-Link kopieren]". 25.2.6 Übersicht zeigt verbundene Konten mit Email, Anbieter, Status (aktiv / pausiert / Fehler / widerrufen) und Datum der letzten Synchronisation. 25.2.7 Verbindung trennen widerruft den Zugriff beim Anbieter und löscht den Kalender-Cache. Optional kann der Mitarbeiter wählen, ob die bisher synchronisierten Termine im externen Kalender bleiben oder dort gelöscht werden. 25.2.8 Die Anmeldungs-Tokens sind verschlüsselt im Ruhezustand gespeichert. Refresh läuft automatisch im Hintergrund. 25.2.9 Bei Token-Widerruf durch den Mitarbeiter (z.B. in den Google-Sicherheitseinstellungen) erscheint Klartext-Banner und Email: "Verbindung zu Google Calendar ist abgelaufen, bitte erneut verbinden, damit deine Termine weiter synchronisiert werden. [Neu verbinden]". 25.2.10 Beim Off-Boarding eines Mitarbeiters (Modul 27) werden seine Kalender-Verbindungen automatisch pausiert; bei Hard-Lösch hart entfernt.

25.3 Welche Events synchronisiert werden

Von HiveGrid in den externen Kalender (Schreib-Pfad):

25.3.1 Booking-Termine (Modul 6): Bei jedem Booking gegen einen Mitarbeiter mit aktiver Kalender-Verbindung wird automatisch ein Spiegel-Event im externen Kalender erstellt. 25.3.2 Projekt-Termine (Modul 4): Pro Termin entscheidet der Mitarbeiter über eine Schalter-Funktion "In meinen Kalender eintragen". 25.3.3 Plantafel-Einträge (Modul 4): Wenn der Mitarbeiter über Mitarbeiter-Einstellung "Plantafel auch im externen Kalender" aktiv hat (Default an). 25.3.4 Aufgaben mit Fälligkeit (Modul 26): optional als ganztägiger Eintrag (Default aus, anpassbar pro Mitarbeiter). 25.3.5 Termine aus Verkaufsfällen / Setter-Closer-Workflow (Modul 3, siehe 3.9.5) [N17, 09.05.2026]: aus dem Verkaufsfall-Detail wird ein Termin für eine andere Person im Mandanten angelegt. Verkaufsfall-Daten (Kunde, Adresse, Volumen, Anlagen-Typ, Fotos) werden in einem mandanten-konfigurierbaren festen Layout in den Termin übernommen. Setter terminiert in 30 Sekunden, Closer hat alle Infos beim Vor-Ort-Termin im Kalender. 25.3.6 Übertragene Felder: Titel (z.B. "Kundentermin Schmidt", "Projekt Heizung Schmidt, Montage Tag 2"), Beschreibung mit Link zurück zu HiveGrid, Adresse aus Projekt/Kunde/Verkaufsfall, Start/Ende/Zeitzone, Teilnehmer (bei Booking wird der Endkunde als Teilnehmer eingeladen, konfigurierbar pro Booking-Seite).

Vom externen Kalender ins HiveGrid (Lese-Pfad, nur für Verfügbarkeits-Berechnung):

25.3.6 Externe Termine werden read-only ins HiveGrid übernommen, ausschließlich um die Verfügbarkeit für Booking und Plantafel zu berechnen. 25.3.7 Sync-Fenster: vergangene 7 Tage + nächste 60 Tage (rollend, in Phase 2 anpassbar). 25.3.8 Privatsphäre: Externe private Termine (mit "Privat"-Markierung beim Anbieter) werden synchronisiert, aber der Titel wird auf "Privat" reduziert. Sie zählen als "belegt" für die Verfügbarkeits-Berechnung. 25.3.9 Nicht synchronisiert: externe Termine mit Status "Frei", abgesagte Termine, Termine außerhalb des Sync-Fensters. 25.3.10 Sichtbarkeit: Externe Event-Inhalte sind nur für den Mitarbeiter selbst und einen Tenant-Admin mit Audit-Berechtigung sichtbar. Niemals für andere Mitarbeiter im Betrieb. Im Booking-/Plantafel-Kontext erscheinen externe Termine nur als "belegt zwischen X und Y", kein Titel-/Inhalts-Leak.

25.4 Konflikt-Auflösung

25.4.1 Synchronisation läuft über Push-Benachrichtigungen vom Anbieter (kein Polling). Push-Abos werden automatisch erneuert (Google ~1 Woche, Microsoft ~3 Tage). 25.4.2 Bei Push-Ausfall Fallback auf 30-Minuten-Polling mit Klartext-Hinweis: "Push-Benachrichtigungen von [Anbieter] sind gerade nicht aktiv. Synchronisation läuft alle 30 Minuten als Sicherheitsnetz.". 25.4.3 Konflikt-Szenario 1: Mitarbeiter editiert Termin im HiveGrid, gleichzeitig editiert ihn jemand im externen Kalender. - HiveGrid versucht den Update zu pushen, wird vom Anbieter mit "Termin wurde inzwischen geändert" abgelehnt. - Standard-Auflösung: externer Stand gewinnt. Der HiveGrid-Edit wird verworfen, der Mitarbeiter bekommt Klartext-Notification: "Dein Termin '[Titel]' wurde gleichzeitig in [Anbieter] geändert, die externe Version wurde übernommen. Du kannst die Änderung manuell wieder einarbeiten. [Original-HiveGrid-Stand anzeigen]". - Der Mitarbeiter kann den verworfenen Stand einsehen und manuell nachziehen. 25.4.4 Konflikt-Szenario 2: Externer Termin gelöscht, HiveGrid hat noch eine Spiegelung. - Spiegelung wird entfernt, der interne Termin (z.B. Booking) bleibt in HiveGrid bestehen. - Klartext: "Der Termin wurde im externen Kalender gelöscht. In HiveGrid bleibt er bestehen. [Im externen Kalender wieder anlegen]". 25.4.5 Konflikt-Szenario 3: HiveGrid-Termin gelöscht. - HiveGrid pusht den Lösch-Befehl an alle gespiegelten externen Kalender. - Falls der externe Termin bereits geändert/gelöscht wurde, wird das stillschweigend hingenommen. 25.4.6 Konflikt-Übersicht in der Kalender-Verbindungs-Detail-Ansicht: Liste der letzten 50 Konflikte mit Klartext und Auflösung. 25.4.7 Wichtige Konflikte (z.B. extern überschriebener Booking-Termin) erzeugen zusätzlich eine Push-Benachrichtigung an den Mitarbeiter (Modul 22).

25.5 Anti-Doppel-Buchung beim Booking

25.5.1 Die Booking-Seite (Modul 6) berechnet verfügbare Slots eines Mitarbeiters auf Basis von: dessen Arbeitszeiten, eigene HiveGrid-Termine, externe Termine mit "Belegt"-Status, Plantafel-Einträge. 25.5.2 Endkunden bekommen niemals den Inhalt externer Termine zu sehen, die Booking-Seite erhält nur "Slot ist frei / belegt". 25.5.3 In seltenen Fällen kann ein externer Termin während eines reservierten Slots erscheinen (Sync-Verzögerung). Der Endkunde wird mit Klartext-Notification informiert und um Re-Buchung gebeten. Realistisch nur bei extremer Sync-Latenz, akzeptable Phase-1-Toleranz.

25.6 Berechtigungen

25.6.1 Eigenen Kalender verbinden: jeder Mitarbeiter darf den eigenen Kalender verbinden und verwalten (Standard). 25.6.2 Kalender-Admin: Tenant-Admin sieht alle Verbindungen (Status-Übersicht), kann gestörte Verbindungen anzeigen und beim Mitarbeiter-Off-Boarding zwangs-trennen. 25.6.3 Ein Mitarbeiter sieht nicht die Verbindungen anderer Mitarbeiter (Privatsphäre), und auch der Tenant-Admin sieht nicht die Inhalte fremder externer Termine, nur die Verbindungs-Status.

25.7 Aktivitäts-Verlauf

25.7.1 Folgende Ereignisse erzeugen einen Aktivitäts-Eintrag: Kalender verbunden, Kalender getrennt, Synchronisations-Fehler (bei wiederholtem Auftreten), Termin extern synchronisiert. 25.7.2 Bewusst nicht im Aktivitäts-Verlauf: jedes einzelne externe Termin-Update (würde den Stream zumüllen).

25.8 Phase 2 / bewusst NICHT in Phase 1

25.8.1 iCal-Feed-URL (read-only Feed für Kalender-Apps ohne OAuth-Anbindung). 25.8.2 Apple/iCloud-Calendar. 25.8.3 FastMail. 25.8.4 Ressourcen-Kalender (Kran, Werkstatt-Heber, Pool-Fahrzeuge als buchbare Ressource). 25.8.5 Tenant-zentrale Verbindung für Ressourcen-Kalender. 25.8.6 Konfigurierbares Sync-Fenster (Phase 1 fest -7/+60 Tage). 25.8.7 Pro-Kalender-Einstellungen (mehrere externe Kalender pro Verbindung mit unterschiedlichen Settings). 25.8.8 Kalender-Farben-Sync. 25.8.9 Smarte Konflikt-Auflösung mit KI-Vorschlag (statt nur "extern gewinnt"). 25.8.10 Erweiterte Zeitzonen-Behandlung (Mitarbeiter in unterschiedlichen Zeitzonen). 25.8.11 Detaillierte Bearbeitung von Serien-Terminen (nur diesen einen Termin vs. komplette Serie).

25.9 Klartext-Fehlertexte (Beispiele)

25.9.1 "Verbindung zu [Anbieter] ist abgelaufen. Bitte neu verbinden, damit deine Termine weiter synchronisiert werden. [Neu verbinden]" 25.9.2 "Du hast HiveGrid die Kalender-Berechtigung im [Anbieter]-Konto entzogen. Synchronisation pausiert. [Neu verbinden]" 25.9.3 "[Anbieter] ist gerade nicht erreichbar, wir holen die letzten Termine sobald die Verbindung wieder steht. Letzte erfolgreiche Synchronisation: [Zeit]." 25.9.4 "[Anbieter] bremst unsere Anfragen, Synchronisation läuft langsamer. Termine erscheinen mit etwas Verzögerung." 25.9.5 "[Email] ist bereits verbunden. Stattdessen die existierende Verbindung anpassen?" 25.9.6 "Dein Termin '[Titel]' wurde gleichzeitig in [Anbieter] geändert, die externe Version wurde übernommen. [Original-Stand anzeigen]" 25.9.7 "Push-Benachrichtigungen von [Anbieter] sind gerade nicht aktiv. Synchronisation läuft alle 30 Minuten als Fallback." 25.9.8 "Dein IT-Admin muss diese Verbindung im [Anbieter]-Tenant zuerst genehmigen. [Admin-Genehmigungs-Link kopieren]" 25.9.9 "Verbindung zu [Email] wird getrennt. [N] synchronisierte Termine bleiben in HiveGrid. Auch in [Anbieter] entfernen? [Nur trennen] [Trennen + extern entfernen]" 25.9.10 "Synchronisation läuft, kann beim ersten Mal ein paar Minuten dauern."

Ende Block 5

Block 6: Spezial-Module

Sechs eigenständige Module, die jeweils einen wichtigen Geschäfts-Workflow abbilden: Formular-Builder als universelles Klebstoff-Modul, Online-Buchung, Angebote mit elektronischer Signatur, das HR-Hub als Quiply-Ablösung für die Mitarbeiterkommunikation, das Kunden-Portal für Geerkens-Endkunden, und das Geschäftsführer-Dashboard.

Modul 5: Form-Builder (Formular-Werkstatt)

Was es tut: Ein voll ausgebauter Drag-and-Drop-Formular-Editor auf Google-Forms-Niveau. Jeder im Betrieb kann ohne Programmierkenntnisse Formulare bauen, vom Kontaktformular auf der Website bis zum Foto-Protokoll-Formular für den Monteur auf der Baustelle. Löst ab: Google Forms, Typeform, Tally, Wufoo, separate Formular-Plugins auf der Tenant-Website. Warum es wichtig ist: Der Form-Builder ist das Klebstoff-Modul. Er verbindet die Außenwelt (Webseiten-Besucher, Endkunden) mit dem CRM (M1), der Lead-Inbox (M2), der Sales-Pipeline (M3), den Projekten (M4), der Plantafel und dem HR-Hub (M14). Ohne ihn sind die anderen Module datenleer.

5.1 Welche Feldtypen stehen in Phase 1 zur Verfügung

5.1.1 Einzeiliger Text (Name, Betreff, Kennung). 5.1.2 Mehrzeiliger Text (Nachricht, Beschreibung). 5.1.3 Zahlen-Eingabe (Ganzzahl oder Dezimalzahl). 5.1.4 Datum, Uhrzeit, Datum mit Uhrzeit. 5.1.5 Auswahl-Liste mit einer Antwort (Dropdown). 5.1.6 Mehrfach-Auswahl-Liste (mehrere Antworten möglich). 5.1.7 Checkbox/Schalter (Ja/Nein). 5.1.8 E-Mail-Adresse mit Format-Prüfung. 5.1.9 Web-Adresse (URL) mit Format-Prüfung. 5.1.10 Telefonnummer mit automatischer Normalisierung auf internationales Format. 5.1.11 Datei-Upload (beliebige Dateitypen). 5.1.12 Foto-Upload mit direktem Zugriff auf die Handy-Kamera (für Monteur-Workflows entscheidend). 5.1.13 Touch-Signatur-Feld (Finger oder Stift auf Handy/Tablet). 5.1.14 Adress-Feld mit Auto-Vervollständigung über Karten-Anbindung. 5.1.15 Überschriften-Element zur Gliederung. 5.1.16 Beschreibungs-Block (Hilfetext mit Formatierung). 5.1.17 Verstecktes Feld (wird automatisch über die Adresse vorausgefüllt, z.B. Kampagnen-Quelle).

5.2 Validierungs-Regeln pro Feld

5.2.1 Pflichtfeld ja/nein. 5.2.2 Mindest- und Maximal-Länge bei Textfeldern. 5.2.3 Mindest- und Maximal-Wert bei Zahlen. 5.2.4 Erlaubte Dateitypen und maximale Dateigröße bei Uploads. 5.2.5 Eigener Fehlertext pro Feld einstellbar (Klartext für den Nutzer).

5.3 Drag-and-Drop-Form-Editor

5.3.1 Felder per Maus/Finger in die gewünschte Reihenfolge ziehen. 5.3.2 Felder duplizieren, löschen, bearbeiten. 5.3.3 Live-Vorschau direkt neben dem Editor, sofort sehen, wie der Nutzer das Formular sieht. 5.3.4 Veröffentlichen mit einem Klick (Status „Entwurf" / „Veröffentlicht" / „Archiviert").

5.4 Datei-Uploads in Forms

5.4.1 Dateien aus Form-Submissions landen automatisch im Tenant-Datei-Speicher. 5.4.2 Pro Feld konfigurierbar: erlaubte Dateitypen, maximale Größe. 5.4.3 Foto-Upload öffnet auf dem Handy direkt die Kamera. 5.4.4 Vorschau aller hochgeladenen Dateien in der Submissions-Detailansicht.

5.5 Acceptance-Signaturen direkt im Formular

5.5.1 Touch-Signatur-Feld (Finger oder Stift). 5.5.2 IP-Adresse und Zeitstempel werden automatisch mit gespeichert (für die rechtliche Beweiskette). 5.5.3 Rechtliche Einordnung: einfache elektronische Signatur, ausreichend für interne Bauabnahmen, Mängel-Protokolle, Wartungs-Quittungen. KEINE qualifizierte eIDAS-Signatur (das macht Modul 7 über PandaDoc/DocuSign).

5.6 Sharing und Embed (Formular ins Internet bringen)

5.6.1 Öffentliche URL pro Formular (z.B. app.hivegrid.de/f/geerkens/kontakt). 5.6.2 Personalisierte Links mit Tracking, Ablaufdatum und Nutzungs-Limit (für gezielte Kampagnen, „diesen Link nur 1x nutzbar"). 5.6.3 Einbettung als iFrame auf der Tenant-Webseite mit automatischem Mit-Wachsen. 5.6.4 JavaScript-Schnipsel für direktes Einbetten in externe Webseiten. 5.6.5 QR-Code-Generator für Druckmaterial (Visitenkarten, Aufsteller, Flyer).

5.7 Form-Submissions als Lead / Kontakt / Deal / Projekt / Aufgabe

Pro Formular werden Aktionen konfiguriert, die nach dem Absenden automatisch ausgeführt werden: 5.7.1 Bestätigungs-E-Mail an den Absender. 5.7.2 E-Mail an interne Empfänger (Vertriebsteam, Backoffice). 5.7.3 Lead in der Lead-Inbox anlegen. 5.7.4 Kontakt im CRM anlegen (mit Auto-Match über E-Mail oder Telefon, falls Kontakt schon existiert). 5.7.5 Deal in der Sales-Pipeline anlegen (mit Auswahl der Ziel-Pipeline). 5.7.6 Projekt in der Auftragspipeline anlegen. 5.7.7 Aufgabe für einen Mitarbeiter erzeugen. 5.7.8 Externen Webhook auslösen (an Drittsysteme). 5.7.9 Automation-Engine triggern (Modul 17). 5.7.10 Daten an KWP übertragen (Modul 19), z.B. Acceptance-Daten direkt in die ERP-Welt. Pro Aktion ist konfigurierbar, welche Form-Felder auf welche Datenfelder im Ziel-System abgebildet werden, und unter welchen Bedingungen die Aktion ausgeführt wird (z.B. „nur wenn das Feld 'Anlagentyp' = 'Wärmepumpe'").

5.8 Submissions-Verwaltung

5.8.1 Liste aller eingegangenen Antworten pro Formular. 5.8.2 Filter nach Datum, Absender, verknüpfter Entität. 5.8.3 Spalten-Konfiguration (welche Form-Felder werden in der Übersichts-Tabelle angezeigt). 5.8.4 CSV-Export gefilterter Antworten. 5.8.5 Detail-Ansicht einer Submission mit allen Antworten, Absender-Metadaten (IP, Browser, Datum), ausgeführten Aktionen mit Erfolgs-Status, verknüpften Datensätzen. 5.8.6 Aktion erneut ausführen (z.B. wenn die Lead-Anlage durch einen vorübergehenden Fehler scheiterte). 5.8.7 PDF-Export einer Submission (für Akten/Archiv). 5.8.8 Archivieren oder DSGVO-konform Löschen einzelner Submissions.

5.9 Spam-Schutz

5.9.1 Honeypot-Felder (unsichtbare Felder, die nur Bots ausfüllen). 5.9.2 hCaptcha-Integration für öffentliche Formulare (nur bei erkanntem Bot-Verkehr aktiv, um echte Nutzer nicht zu nerven). 5.9.3 Rate-Limits pro IP-Adresse. 5.9.4 Drosselung bei verdächtigen Mustern (sehr schnelles Ausfüllen, gleicher Inhalt mehrfach).

5.10 SHK-Branchen-Vorlagen (vorinstalliert beim neuen Tenant)

5.10.1 „Kontakt-Anfrage", Lead-Formular für die Webseite. 5.10.2 „Sales-Aufnahme vor Ort", Vertriebler nimmt beim Erstbesuch technische Daten auf. 5.10.3 „Foto-Checkliste", Monteur dokumentiert die Bestandsanlage mit Fotos. 5.10.4 „Acceptance-Protokoll Anlage", Bauabnahme mit Touch-Signatur. 5.10.5 „Wartungs-Buchung", Endkunde meldet Wartungstermin an. 5.10.6 „Krankmeldung", interne Mitarbeiter-Vorlage (an HR-Hub gekoppelt). 5.10.7 „Urlaubsantrag", interne Mitarbeiter-Vorlage. 5.10.8 „Customer-Feedback-Survey", wird nach Auftrags-Abschluss an den Kunden geschickt.

5.11 Berechtigungen

5.11.1 Geschäftsführung: voller Zugriff inklusive Admin und Vorlagen. 5.11.2 Vertriebsleitung / Projektleitung / Marketing: dürfen Formulare anlegen, veröffentlichen und Submissions exportieren. 5.11.3 Vertriebler / Büro: dürfen Formulare anlegen und bearbeiten, eigene Submissions sehen. 5.11.4 Monteur: kann nur eigene Formulare und Submissions sehen, ausfüllen und absenden.

5.12 Phase 2 / bewusst NICHT in Phase 1

5.12.1 Verzweigungslogik („Wenn Anlagentyp = Gas, zeige diese Felder, sonst andere"). 5.12.2 Mehrseitige Formulare mit Zwischenspeichern und Fortsetzen-später. 5.12.3 Form-Statistiken und Charts (Auswertungs-Visualisierungen). 5.12.4 Cross-Field-Validation („Datum 2 muss nach Datum 1 liegen"). 5.12.5 A/B-Testing (zwei Varianten gegeneinander testen). 5.12.6 Wiederhol-Felder („füge weitere Anlage hinzu"). 5.12.7 Marketplace mit Form-Vorlagen anderer Tenants.

5.13 Klartext-Fehlertexte (Beispiele)

5.13.1 Feld ohne Beschriftung im Editor: „Feld 3 hat keinen Label, bitte ausfüllen." 5.13.2 URL-Konflikt: „Die URL 'kontakt' wird bereits von einem anderen Formular genutzt." 5.13.3 Pflichtfeld ohne Validierung: „Feld 'E-Mail' ist Pflicht, aber keine E-Mail-Format-Prüfung gesetzt, soll ich das ergänzen?"

Modul 6: Booking (Online-Termin-Buchung im Calendly-Stil)

Was es tut: Öffentliche Buchungsseiten pro Tenant, auf denen Endkunden selbst freie Termine sehen und buchen. Die Verfügbarkeit wird in Echtzeit aus den verbundenen Google-/Microsoft-Kalendern der Mitarbeiter berechnet. Nach der Buchung gibt es eine automatische Bestätigungs-Mail, der Termin landet im internen Kalender und im externen Mitarbeiter-Kalender, und es entsteht entweder ein neuer Lead (Erstkunde) oder eine Aktivität am bestehenden Kontakt. Löst ab: HubSpot-Booking-Tool, Calendly, externe Terminbuchungs-Dienste. Warum es wichtig ist: Vertriebsleitung und Wartungs-Disposition gewinnen massiv Zeit, weil das Hin-und-Her per Telefon und E-Mail entfällt. Der Endkunde sieht direkt, wann er einen Termin bekommt.

6.1 Buchungsseiten anlegen

6.1.1 Pro Anwendungsfall eine eigene Buchungsseite („Wartungstermin-Beratung", „Erstgespräch Photovoltaik", „Service-Termin"). 6.1.2 Pro Buchungsseite einstellbar: Titel, Beschreibung mit Formatierung, Dauer (15/30/45/60/90/120 Minuten), URL-Bestandteil (z.B. wartungstermin). 6.1.3 Mehrere Mitarbeiter (Provider) pro Buchungsseite, z.B. drei Vertriebler teilen sich eine Buchungsseite. 6.1.4 Drei Zuteilungs-Strategien: - Round-Robin: System wählt automatisch den Mitarbeiter mit den wenigsten Buchungen der letzten 30 Tage. - Endkunde wählt selbst aus einer Liste der Mitarbeiter (mit Foto und Namen). - „Erster, der frei ist", Slots werden zusammengeführt, der Termin geht an den Mitarbeiter, der zuerst frei wird. 6.1.5 Vorschau-Funktion (öffnet die fertige Buchungsseite in einem neuen Tab). 6.1.6 Veröffentlichen oder Verstecken (z.B. saisonale Buchungsseite).

6.2 Verfügbarkeits-Logik

Jeder Mitarbeiter pflegt seine eigene Verfügbarkeit: 6.2.1 Wöchentliche Standard-Regel pro Wochentag (z.B. Mo-Fr 09:00-12:00 + 14:00-17:00 mit Mittagspause). 6.2.2 Datums-Ausnahmen (Urlaub, Schulungen, Sondertermine), entweder ganzer Tag blockiert oder eigene Zeitfenster. 6.2.3 Zeitzone pro Regel (für Tenants mit Mitarbeitern in verschiedenen Ländern). 6.2.4 Bulk-Aktion „diese Woche bin ich nicht verfügbar" erzeugt 7 Ausnahmen mit einem Klick. Die Berechnung freier Slots zur Laufzeit: 6.2.5 Standard-Regel des Wochentags wird genommen. 6.2.6 Datums-Ausnahmen werden überlagert. 6.2.7 Bestehende Termine (mit Pufferzeiten) werden abgezogen. 6.2.8 Externe Kalender-Termine aus Google/Microsoft werden abgezogen, wenn der Mitarbeiter privat einen Zahnarzt-Termin im Google-Kalender einträgt, fällt dieser Slot automatisch raus. 6.2.9 Mindest-Vorlauf wird abgezogen (z.B. „nicht in den nächsten 4 Stunden buchbar"). 6.2.10 Maximal-Vorlauf wird angewendet (z.B. „nicht weiter als 60 Tage in der Zukunft buchbar").

6.3 Zeitfenster und Pufferzeiten

6.3.1 Pufferzeit vor dem Termin (Vorbereitung). 6.3.2 Pufferzeit nach dem Termin (Nachbereitung, Anfahrt zum nächsten). 6.3.3 Slot-Raster konfigurierbar (Slots werden nur an Vielfachen von 15/30/60 Minuten angeboten). 6.3.4 Mindest-Vorlauf in Stunden. 6.3.5 Maximal-Vorlauf in Tagen.

6.4 Verknüpfung mit Kalender

6.4.1 Termin wird automatisch in den internen HiveGrid-Kalender des Mitarbeiters eingetragen. 6.4.2 Termin wird zusätzlich in den verbundenen Google-/Microsoft-Kalender geschoben, der Mitarbeiter sieht den Termin auf seinem Handy / in seinem Outlook. 6.4.3 Bei Stornierung oder Verschiebung: externer Kalender-Eintrag wird ebenfalls aktualisiert. 6.4.4 Bei Sync-Fehler (z.B. Token abgelaufen): Klartext-Hinweis im Termin-Detail mit „Erneut versuchen"-Funktion.

6.5 Buchungs-Bestätigungen

6.5.1 Pro Buchungsseite konfigurierbarer E-Mail-Text mit Platzhaltern (Datum, Uhrzeit, Mitarbeiter, Kunden-Name, Tenant-Firmenname). 6.5.2 Versand über die Tenant-Absender-Domain (Modul 9), damit die Mail vom Tenant kommt und nicht von HiveGrid. 6.5.3 Add-to-Calendar-Funktion für den Endkunden (Standard-Kalender-Format zum Importieren). 6.5.4 Bei Sende-Fehler bleibt der Termin bestehen und der Mitarbeiter bekommt einen internen Hinweis, den Endkunden manuell zu kontaktieren.

6.6 Endkunden-Flow auf der öffentlichen Buchungsseite

6.6.1 Schritt 1: Datum auswählen (Tage ohne Verfügbarkeit sind ausgegraut), dann Zeitslot. 6.6.2 Schritt 2: Daten eingeben (Vor-/Nachname, E-Mail, Telefon optional). Wenn ein Aufnahme-Formular aus Modul 5 verknüpft ist, wird dieses stattdessen angezeigt. 6.6.3 Schritt 3: DSGVO-Hinweis und Akzeptanz-Checkbox. 6.6.4 Schritt 4: Bestätigung mit allen Daten und Add-to-Calendar. 6.6.5 Bei Race-Condition (zwei Endkunden buchen gleichzeitig den gleichen Slot): freundliche Klartext-Meldung und sofortige Anzeige aktueller Alternativen.

6.7 Embed-Code für externe Webseiten

6.7.1 iFrame-Variante (kopierbarer HTML-Code für die Tenant-Webseite, ohne HiveGrid-Branding). 6.7.2 Klartext-Hilfe: „Für WordPress: HTML-Block. Für Webflow: Embed-Element."

6.8 Buchungen verwalten (interne Sicht)

6.8.1 Übersicht aller Buchungen mit Filter (Mitarbeiter, Buchungsseite, Status, Zeitraum). 6.8.2 Detail-Ansicht: Termin-Daten, Endkunden-Daten, Aufnahme-Formular-Antworten, interne Notizen. 6.8.3 Status setzen: „hat stattgefunden" / „Kunde nicht erschienen". 6.8.4 Termin stornieren mit Pflicht-Begründung (Endkunde bekommt automatische Storno-Mail). 6.8.5 Termin verschieben (Slot-Picker erneut, Endkunde bekommt Update-Mail mit neuem Termin). 6.8.6 Mitarbeiter neu zuweisen (mit Klartext-Hinweis: „Termin wird im Kalender von Alt entfernt und bei Neu eingetragen, Endkunde bekommt Update-Mail").

6.9 Verknüpfungen mit anderen Modulen

6.9.1 Neue E-Mail-Adresse → automatisch neuer Lead in der Lead-Inbox mit Quelle „Buchung". 6.9.2 E-Mail-Adresse bekannt → Aktivität am bestehenden Kontakt. 6.9.3 Aufnahme-Formular-Antworten landen vollwertig in Modul 5. 6.9.4 Im Activity-Stream des Kontakts erscheint „Termin gebucht" / „Termin stattgefunden" / „Termin storniert" usw. 6.9.5 Falls der Kontakt in einem Deal ist, taucht der Termin auch dort auf.

6.10 Berechtigungen

6.10.1 Die öffentliche Buchungsseite ist immer ohne Login erreichbar (das ist der Sinn). 6.10.2 Intern: Mitarbeiter sehen nur eigene Termine, Vertriebsleitung sieht alle, Geschäftsführung darf Buchungsseiten anlegen und löschen.

6.11 Phase 2 / bewusst NICHT in Phase 1

6.11.1 Endkunden-Storno-/Reschedule-Link mit Token (in Phase 1 nur durch Tenant-Mitarbeiter manuell). 6.11.2 Automatische Erinnerungs-Mails 24h und 1h vor dem Termin. 6.11.3 SMS-Erinnerungen (kostenpflichtige Zusatz-Funktion). 6.11.4 Eigene Domain für Buchungsseiten (termine.geerkens.de). 6.11.5 Vorauszahlung / Anzahlung über Legacy-Provider. 6.11.6 Gruppen-Termine (mehrere Endkunden für einen Slot). 6.11.7 KI-Buchungs-Assistent.

6.12 Klartext-Fehlertexte (Beispiele)

6.12.1 URL bereits vergeben: „Diese URL ist schon vergeben, wähle eine andere." 6.12.2 Buchungsseite ohne Mitarbeiter speichern: „Mindestens 1 Mitarbeiter muss zugewiesen sein, sonst können Endkunden nicht buchen." 6.12.3 Slot kurz vor Submit weg: „Ohje, dieser Slot wurde gerade gebucht. Hier sind aktuelle Alternativen." 6.12.4 Kalender-Sync-Fehler: „Konnte Termin nicht im Google-Kalender von [Mitarbeiter] eintragen. [Erneut versuchen]"

Modul 7: Angebot + elektronische Signatur

Was es tut: Angebote als PDF werden über eine externe Signatur-Plattform (PandaDoc oder DocuSign) zur rechtsgültigen Unterschrift verschickt. Sobald der Kunde unterschrieben hat, kommt das signierte PDF automatisch zurück und der Deal-Status springt auf „gewonnen". Löst ab: Manueller Versand per E-Mail mit „bitte unterschreiben und zurückschicken", Ausdrucken und Einscannen. Warum es wichtig ist: Schnellere Abschlüsse, sauberer Audit-Trail, klare Rechtssicherheit über die Signatur-Plattform.

7.1 Anbindung an PandaDoc und DocuSign

7.1.1 Tenant-Admin verbindet das Tenant-Konto mit PandaDoc (Standard) oder DocuSign über einen Sicherheits-Login (OAuth), siehe Apps-Engine Modul 33a. 7.1.2 Beide Plattformen funktionieren gleichwertig, Tenant entscheidet, welche er nutzt. 7.1.3 Pro Tenant kann eine Plattform als Standard markiert werden.

7.2 Kein eigenes eIDAS: was heißt das

7.2.1 HiveGrid baut KEINE eigene Signatur-Engine. Alles, was rechtlich relevante Unterschriften betrifft, läuft über PandaDoc oder DocuSign, denn die haben die Zertifizierungen bereits, die für eIDAS-konforme Signaturen nötig sind. 7.2.2 HiveGrid liefert nur die Anbindung: PDF an Plattform schicken, Status-Updates empfangen, signiertes PDF speichern. 7.2.3 Der Geschäftsführer (Noah) muss sich nicht um eIDAS-Compliance kümmern, das ist Sache von PandaDoc/DocuSign.

7.3 PDF-Upload und Sende-Workflow im Deal

7.3.1 Im Deal-Detail Funktion „Angebot zur Signatur senden". 7.3.2 Schritt 1: PDF auswählen (aus dem Tenant-Datei-Speicher) oder neu hochladen. 7.3.3 Schritt 2: Unterschreiber konfigurieren, mindestens der Kunde, optional weitere (Zeuge, Vertriebsleiter). Pro Unterschreiber: Name (vorausgefüllt aus Kontakt), E-Mail, Rolle. 7.3.4 Schritt 3: Reihenfolge wählen, entweder seriell („erst Kunde, dann Vertriebsleiter") oder parallel (alle gleichzeitig). 7.3.5 Schritt 4: Plattform auswählen (Standard ist vorbelegt). 7.3.6 Schritt 5: Optional Felder im PDF platzieren (in Phase 1 in der PandaDoc/DocuSign-Oberfläche, in Phase 2 direkt in HiveGrid). 7.3.7 Senden, die Plattform schickt automatisch eine E-Mail an alle Unterschreiber. Im Deal erscheint Status „gesendet" und ein Eintrag im Activity-Stream.

7.4 Status-Tracking

Die Signatur-Plattform meldet automatisch zurück (per Webhook), was passiert: 7.4.1 Unterschreiber hat das Dokument geöffnet. 7.4.2 Unterschreiber hat unterschrieben. 7.4.3 Unterschreiber hat abgelehnt. 7.4.4 Alle Unterschreiber sind fertig, Dokument vollständig signiert. 7.4.5 Dokument ist abgelaufen (Frist verstrichen). Bei jedem Status-Update: Eintrag im Activity-Stream des Deals, Push-Notification an den verantwortlichen Vertriebler. 7.4.6 Bei vollständiger Signatur: signiertes PDF wird automatisch heruntergeladen und im Tenant-Datei-Speicher abgelegt. 7.4.7 Optional automatischer Stage-Wechsel zu „gewonnen" (Tenant-konfigurierbar). 7.4.8 Bei Ablehnung: Klartext-Notification + optional Auto-Wechsel zu „verloren".

7.5 Detail-Sicht im Deal

7.5.1 Liste aller Signatur-Dokumente pro Deal mit Status, Versand-Datum, Signatur-Datum. 7.5.2 Pro Unterschreiber Status (offen / angeschaut / unterschrieben / abgelehnt). 7.5.3 Original-PDF und signiertes PDF zum Download. 7.5.4 Funktionen: Erinnerung an Unterschreiber schicken (über die Plattform), Dokument widerrufen, Dokument neu senden mit angepasstem PDF, Status manuell aktualisieren.

7.6 Acceptance-Signatur über Formular (NICHT Modul 7)

Die einfache elektronische Bauabnahme-Signatur läuft NICHT über Modul 7, sondern direkt über den Form-Builder (Modul 5): 7.6.1 Touch-Signatur-Feld im Acceptance-Protokoll-Formular. 7.6.2 IP-Adresse und Zeitstempel werden automatisch mitgespeichert. 7.6.3 Rechtlich: einfache elektronische Signatur, ausreichend für interne Bauabnahme. Reicht für Geerkens-Tagesgeschäft. 7.6.4 Modul 7 mit PandaDoc/DocuSign nutzt der Tenant nur für Angebote und ähnliche Dokumente, bei denen er eine fortgeschrittene oder qualifizierte Signatur möchte.

7.7 Berechtigungen

7.7.1 Geschäftsführung: voller Zugriff inklusive Plattform-Anbindung verwalten. 7.7.2 Vertriebsleitung / Vertriebler: dürfen Dokumente versenden, Status sehen, widerrufen. 7.7.3 Andere Rollen: keine Berechtigung (Signaturen sind sensibel und nur im Deal-Kontext relevant).

7.8 Phase 2 / bewusst NICHT in Phase 1

7.8.1 Versionierung von Angeboten (V1, V2, V3 mit Diff-Anzeige). 7.8.2 Felder direkt in HiveGrid auf dem PDF platzieren (statt in der Plattform-Oberfläche). 7.8.3 Eigene eIDAS-konforme qualifizierte Engine über deutsche Anbieter (D-Trust, Signaturit), falls je nötig. 7.8.4 Bulk-Send (mehrere Angebote auf einmal versenden).

7.9 Klartext-Fehlertexte (Beispiele)

7.9.1 PDF zu groß: „Datei ist größer als 25 MB. Bitte komprimieren." 7.9.2 Unterschreiber ohne E-Mail: „Unterschreiber 'Max Mustermann' hat keine E-Mail-Adresse. Bitte ergänzen." 7.9.3 Plattform nicht erreichbar: „Verbindung zu PandaDoc gerade nicht erreichbar. Versuche es in 5 Minuten erneut."

Modul 14: HR-Hub (Mitarbeiterplattform)

Was es tut: Eine vollständige Mitarbeiter-Plattform mit Bekanntmachungen, Urlaubs- und Krankmeldungs-Workflow, Lohnabrechnungen, Mitarbeiter-Verzeichnis, Standorten, Dokumenten-Verwaltung, Antrags-System (Spesen, Hardware, Schulungen), Surveys und einem verschlüsselten Team-Passwort-Safe. Mobile-First konzipiert, damit der Monteur auf der Baustelle die Krankmeldung schnell vom Handy melden und seine Lohnabrechnung anschauen kann. Löst ab: Quiply (komplett, das ist der explizite Anspruch), Personio-Light-Funktionen, Outlook-Verteiler-Mails, ausgedruckte Urlaubsanträge, separate Passwort-Manager-Tools. Warum es wichtig ist: Mitarbeiterkommunikation und Personal-Selfservice sind zentral für einen 30-50-Mann-Handwerksbetrieb. Quiply kostet Geld und kann nicht mit dem Rest des Systems sprechen, der HR-Hub kann das. Plus: Krankmeldung und Urlaub fließen direkt in die Plantafel und stören die Disposition nicht mehr.

14.1 Mitarbeiter-Stammdaten (eigenes Profil + Verzeichnis)

14.1.1 Pro Mitarbeiter ein erweitertes HR-Profil mit Personalnummer, Geburtsdatum, Eintrittsdatum, Position, Team, Standort, Diensttelefon, Privattelefon, Privatadresse, Notfallkontakt, Vorgesetzter, kurzer Bio, Avatar. 14.1.2 Der Mitarbeiter pflegt bestimmte Felder selbst (Privattelefon, Privatadresse, Notfallkontakt, Bio, Avatar). Andere Felder pflegt nur der HR-Admin (Personalnummer, Position, Vorgesetzter, Eintrittsdatum, Team, Standort). 14.1.3 Mitarbeiter-Verzeichnis sichtbar für alle Tenant-User: Name, Position, Team, Standort, Diensttelefon, E-Mail, Vorgesetzter, mit direkter Telefon-Klick-Funktion (Click-to-Call), Mail-Funktion und Chat-Start. 14.1.4 Filter und Suche im Verzeichnis (nach Standort, Team, Position, Vorgesetztem). 14.1.5 Bei neuem Tenant-User wird automatisch ein leeres HR-Profil erzeugt.

14.2 Standorte (Niederlassungen)

14.2.1 Pro Tenant beliebig viele Standorte mit Name, Adresse, Telefon, E-Mail, Anfahrts-Hinweisen, Öffnungszeiten, Foto und Karten-Vorschau. 14.2.2 Mitarbeiter werden Standorten zugeordnet (für die richtige Feiertags-Berechnung im Urlaubsantrag, Bundesland-genau).

14.3 Schwarzes Brett (interne Bekanntmachungen)

14.3.1 Geschäftsführung und Backoffice posten firmenweite Bekanntmachungen mit Titel, Text (formatierbar), Anhängen, Empfänger-Auswahl (alle / bestimmte Gruppen / bestimmte Standorte / einzelne Personen). 14.3.2 Bekanntmachungen anpinnen (oben in der Liste). 14.3.3 Veröffentlichungs-Zeitpunkt planen (sofort oder zu späterem Zeitpunkt) und automatisches Ablaufdatum. 14.3.4 Lese-Bestätigung erforderlich ja/nein, bei „ja" muss der Mitarbeiter explizit klicken, dass er gelesen hat (z.B. wichtige Sicherheitshinweise). 14.3.5 Lese-Übersicht für die Geschäftsführung: Wer hat gelesen / bestätigt / wer noch nicht. 14.3.6 Reaktionen mit Emoji (eine pro Mitarbeiter pro Bekanntmachung). 14.3.7 Kommentare unter Bekanntmachungen mit einer Antwort-Ebene. 14.3.8 Push-Benachrichtigung an alle Empfänger bei Veröffentlichung.

14.4 Urlaubsanträge und Genehmigung

14.4.1 Mitarbeiter stellt Urlaubsantrag über ein Formular (Modul 5 Form-Vorlage) mit Start-/End-Datum, Antragsart (bezahlter Urlaub / unbezahlter Urlaub / Überstunden-Ausgleich / Sonderurlaub), Begründung optional, Genehmiger. 14.4.2 Standard-Genehmiger ist der eingetragene Vorgesetzte aus dem Profil, kann manuell überschrieben werden. 14.4.3 Anzahl Arbeitstage wird automatisch berechnet (ohne Wochenende und Bundesland-spezifische Feiertage). 14.4.4 Konflikt-Check als Klartext-Hinweis: „Du hast für diesen Zeitraum bereits einen genehmigten Urlaub", nicht-blockierend. 14.4.5 Genehmiger bekommt Push und E-Mail. 14.4.6 Genehmiger kann genehmigen (mit optionaler Notiz), ablehnen (mit Pflicht-Begründung), oder Rückfragen stellen. 14.4.7 Bei Genehmigung: automatischer Eintrag im Kalender des Mitarbeiters und im Tenant-Kalender „Team-Urlaube", Konflikt-Indikator in der Plantafel (Modul 4). 14.4.8 Bei Ablehnung: Klartext-Begründung wird dem Mitarbeiter angezeigt. 14.4.9 Mitarbeiter kann Antrag zurückziehen, solange er noch nicht entschieden ist.

14.5 Krankmeldungen

14.5.1 Krankmeldung über ein Formular ohne Genehmigungs-Workflow, sofort wirksam. 14.5.2 Felder: Start-Datum, voraussichtliches Rückkehr-Datum (optional), AU-Bescheinigung vorhanden ja/nein, AU-Bescheinigungs-Datei-Upload (verschlüsselt gespeichert), Notiz. 14.5.3 Automatischer Versand an Backoffice und direkten Vorgesetzten (Push und E-Mail). 14.5.4 Konflikt-Indikator in der Plantafel, der Projektleiter sieht sofort, dass für den Krankheits-Zeitraum Termine umgeplant werden müssen. 14.5.5 Automatischer Reminder bei fehlender AU-Bescheinigung ab dem dritten Tag (deutsches Recht). 14.5.6 Verlängerung möglich (Datum aktualisieren). 14.5.7 Rückkehr melden, Status springt auf „zurück". 14.5.8 Backoffice darf eine Krankmeldung im Auftrag eines Mitarbeiters erfassen (z.B. wenn Mitarbeiter nicht selbst melden kann). 14.5.9 STRENG: AU-Bescheinigungen sind nur für HR-Admin und Backoffice einsehbar, der direkte Vorgesetzte sieht nur „krank von X bis Y", keine medizinischen Details.

14.6 Lohnabrechnungen (Payslips)

14.6.1 Backoffice lädt PDFs hoch, entweder einzeln pro Mitarbeiter+Monat oder als Bulk-Upload. 14.6.2 Bulk-Upload mit automatischer Zuordnung über Personalnummer im Dateinamen (z.B. 12345-2026-04.pdf) oder Nachname. 14.6.3 Vor dem endgültigen Speichern: Match-Vorschau mit Confidence-Anzeige (eindeutig/wahrscheinlich/unklar). Unklare Matches manuell zuordnen. 14.6.4 Automatische Push- und E-Mail-Benachrichtigung an Mitarbeiter „Neue Lohnabrechnung verfügbar". 14.6.5 Mitarbeiter sieht eigene Lohnabrechnungen sortiert nach Monat, mit PDF-Viewer und Download. 14.6.6 Lese-Status wird automatisch gesetzt, sobald der Mitarbeiter die PDF öffnet (Compliance-Nachweis). 14.6.7 Korrektur-Lauf: gleicher Monat darf mit Notiz „Korrektur" doppelt hochgeladen werden. 14.6.8 STRENG: nur Mitarbeiter selbst und HR-Admin sehen die Lohnabrechnung. Niemand sonst, auch der direkte Vorgesetzte nicht. 14.6.9 Lohnabrechnungen sind 10 Jahre aufzubewahren (deutsches Steuerrecht), Hard-Delete erfordert sekundäre Bestätigung mit Klartext-Warnung.

14.7 Dokumente für Mitarbeiter (Verträge, Bescheinigungen, Zeugnisse)

14.7.1 Pro Mitarbeiter Dokumenten-Liste mit Typ (Vertrag / Zeugnis / Bescheinigung / Ausweis / Führerschein / sonstiges), Titel, Beschreibung, Datei, Gültigkeitszeitraum. 14.7.2 Sichtbarkeit pro Dokument: „Mitarbeiter und Backoffice" oder „nur Backoffice" (z.B. interne Notizen). 14.7.3 Mitarbeiter kann eigene Dokumente hochladen (z.B. neuen Führerschein nach Verlängerung). 14.7.4 Backoffice kann Dokumente für Mitarbeiter hochladen (z.B. Arbeitsvertrag). 14.7.5 Dokumente mit Gültigkeits-Ende (z.B. Führerschein) werden vom System überwacht und vor Ablauf automatisch erinnert.

14.8 Upload-Erinnerungen für ablauf-überwachte Dokumente

14.8.1 HR-Admin definiert Erinnerungs-Regeln: „Führerschein-Scan jährlich von allen Außendienst-Mitarbeitern", „Erste-Hilfe-Schein alle 2 Jahre". 14.8.2 Empfänger-Auswahl (alle / Gruppe / Standort / einzelne Personen). 14.8.3 Wiederholungs-Logik: einmalig / jährlich / alle N Monate / X Tage vor Ablaufdatum (bei Dokumenten mit Gültigkeits-Ende). 14.8.4 Automatische Push- und E-Mail-Benachrichtigung an betroffene Mitarbeiter. 14.8.5 Bei Überfälligkeit (>7 Tage): Eskalation an Vorgesetzten und HR-Admin. 14.8.6 Mitarbeiter klickt Erinnerung → wird direkt zum Upload-Workflow geleitet (oder zu einem verknüpften Formular für Zusatz-Felder wie „Fahrerlaubnis-Klasse"). 14.8.7 Pflicht-Erinnerungen blockieren den HR-Hub mit Klartext-Hinweis, bis erledigt, andere Module bleiben aber bedienbar.

14.9 Generische Anträge mit Vorlagen

14.9.1 HR-Admin definiert Antrags-Vorlagen für wiederkehrende Anträge: Spesenabrechnung (mit Beleg-Upload), Hardware-Anfrage, Schulung/Weiterbildung, Arbeitszeugnis, sonstiger Antrag. 14.9.2 Pro Vorlage: Standard-Genehmiger (direkter Vorgesetzter / fixer User / Rolle / Gruppe), verknüpftes Formular aus Modul 5, Anweisungs-Text. 14.9.3 Mitarbeiter wählt Vorlage, füllt Formular aus, hängt Belege an, gibt Priorität an (normal / dringend), schickt ab. 14.9.4 Genehmiger bekommt Push und E-Mail, sieht das Formular ausgefüllt, kann genehmigen / ablehnen / rückfragen / weiter delegieren. 14.9.5 Kommentare zwischen Antragsteller und Genehmiger (interne Notizen sind für den Antragsteller unsichtbar).

14.10 Mitarbeiter-Surveys (Umfragen)

14.10.1 HR-Admin legt Umfragen an mit verschiedenen Fragetypen (Text, Multi-Auswahl, Sterne-Bewertung, NPS, Datum). 14.10.2 Anonyme oder namentliche Umfragen. 14.10.3 Empfänger-Auswahl (alle / Gruppe / Standort). 14.10.4 Auswertung als Aggregat (Anzahl pro Antwort, Durchschnitts-Bewertung, NPS-Score). 14.10.5 Sichtbarkeit der Auswertung konfigurierbar (nur Ersteller / HR-Admin / alle Teilnehmer). 14.10.6 CSV-Export der Auswertung. 14.10.7 Reminder an Nicht-Teilnehmer.

14.11 Quick-Links und Resources (kuratierte Sammlungen)

14.11.1 Quick-Links: Schnellzugriffe auf häufig genutzte Tools (Symbol + Beschriftung + Adresse), mit Empfänger-Filter. 14.11.2 Resources: Sammlung von internen und externen Ressourcen, gruppiert nach Kategorie (Onboarding-Material, Sicherheits-Hinweise, IT-Anleitungen). 14.11.3 Pro Ressource: Typ (interner Link / externer Link / Datei / Text), Beschreibung, Empfänger-Filter.

14.12 Onboarding (Drittanbieter-Anbindung) [N18, 09.05.2026]

Anpassung gem. Anmerkung Noah, 09.05.2026: Onboarding ist ein eigenes großes Thema mit Videos, Lern-Pfaden, Quizzen und Fortschritts-Tracking. Spezialisierte Plattformen (Memberspot, Boobora, vergleichbare) leisten das deutlich besser als ein nativ in HiveGrid gebauter Checklisten-Workflow. HiveGrid dient als Anker und Sichtbarkeits-Schicht, die eigentliche Onboarding-Plattform bleibt extern. Eine native Vollumsetzung wäre für Phase 2 zu evaluieren.

14.12.1 Drittanbieter-Anbindung als Phase-1-Lösung über die Apps-Engine (Modul 33a). Konkret unterstützt: Memberspot und Boobora. Weitere Anbieter über das Adapter-Pattern später. 14.12.2 Onboarding-Reiter im Mitarbeiter-Profil: zeigt den Fortschritt der Person in der angebundenen Plattform (z. B. „4 von 12 Modulen erledigt", „Sicherheitsbelehrung in 2 Tagen fällig"), mit Direktlink in die Drittanbieter-Plattform für die eigentliche Inhalts-Bearbeitung. 14.12.3 Daten-Synchronisation mit der Drittanbieter-Plattform: Modul-Abschlüsse, Zertifikats-Datum, Quiz-Ergebnisse, Fortschritts-Prozent. Sync-Richtung primär Plattform → HiveGrid (lesen). Neuer Mitarbeiter wird beim Anlegen in HiveGrid automatisch in der Drittanbieter-Plattform registriert (push einmalig), Folgeänderungen am Profil werden gespiegelt. 14.12.4 HR-Admin-Sicht: Übersicht aller Mitarbeiter mit Onboarding-Status (laufend / abgeschlossen / im Verzug). Filter nach Standort, Rolle, Eintritts-Datum. 14.12.5 Erinnerungen über Automation-Engine (Modul 17): aus dem synchronisierten Status können Erinnerungen automatisch ausgelöst werden („Sicherheitsbelehrung läuft in 7 Tagen ab, Push an Mitarbeiter und HR"). 14.12.6 Begleitende Aufgaben in HiveGrid bleiben möglich für rein operative Onboarding-Punkte, die kein Lern-Inhalt sind: „Schlüssel ausgeben", „IT-Zugang einrichten", „Arbeitskleidung übergeben". Diese Aufgaben (Modul 26) ergänzen den Drittanbieter-Inhalt, ersetzen ihn aber nicht. 14.12.7 Phase 2 (zu evaluieren): native Onboarding-Plattform direkt in HiveGrid (Lern-Pfade, Video-Upload, Quizze, Zertifikate). Nur dann sinnvoll, wenn Marktforschung bei vielen Mandanten Bedarf zeigt und die Drittanbieter-Anbindung an Grenzen stößt.

14.13 Verschlüsselter Team-Passwort-Safe

14.13.1 Team-Vaults pro Bereich (z.B. „IT-Disposition", „Marketing"). 14.13.2 Pro Vault: Einträge mit Titel, Benutzername, Passwort, URL, Notiz, Tags. 14.13.3 Werte sind in der Datenbank verschlüsselt (AES-256-GCM mit Tenant-eigenem Schlüssel im KMS), niemals im Klartext gespeichert. 14.13.4 Werte werden in der Liste NIE angezeigt, nur Titel und Tags. Reveal-Funktion pro Wert. 14.13.5 Beim Reveal: Audit-Log-Eintrag „User X hat Eintrag Y am Z entschlüsselt". 14.13.6 Copy-to-Clipboard-Funktion mit automatischem Löschen nach 30 Sekunden. 14.13.7 Zugriff pro Vault konfigurierbar (Lesen / Schreiben / Vault-Verwaltung), pro Person, Gruppe oder Rolle. 14.13.8 Bei Mitarbeiter-Austritt: Vault-Zugriff automatisch entzogen, aktive Sessions beendet. 14.13.9 Empfehlung: 2-Faktor-Authentifizierung Pflicht für Vault-Admins.

14.14 Mobile-First für Monteure (LP-2)

14.14.1 Krankmeldung in 3 Klicks vom Handy melden. 14.14.2 Foto-Upload für AU-Bescheinigung über Handy-Kamera. 14.14.3 Lohnabrechnung anschauen mit PDF-Viewer auf dem Handy. 14.14.4 Schwarzes Brett auch auf dem Handy lesbar (gerendert für kleine Screens). 14.14.5 Verzeichnis mit Click-to-Call-Funktion. 14.14.6 Push-Notifications für neue Bekanntmachungen, Genehmigungs-Entscheidungen, neue Lohnabrechnungen.

14.15 Verknüpfung mit Plantafel und Kalender

14.15.1 Genehmigte Urlaube und aktive Krankmeldungen erscheinen als Konflikt-Indikator in der Plantafel (Modul 4), der Projektleiter sieht beim Termin-Vergeben sofort, wer fehlt. 14.15.2 Genehmigte Urlaube landen automatisch im Kalender des Mitarbeiters und im Tenant-Kalender „Team-Urlaube". 14.15.3 Sync zu Google/Microsoft-Kalender (Modul 25), Außer-Haus-Anzeige.

14.16 Datenschutz und Aufbewahrung

14.16.1 Vier Sensibilitäts-Stufen: - Öffentlich im Tenant: Verzeichnis-Stammdaten, Bekanntmachungen, Standorte. - Mitarbeiter-vertraulich: Privattelefon, Privatadresse, Notfallkontakt, eigene Dokumente, eigene Anträge. - Streng vertraulich: Lohnabrechnungen, AU-Bescheinigungen, Personalnummer, vertragliche Detail-Dokumente, nur mit Sonder-Berechtigung. - Verschlüsselt: Passwort-Safe-Inhalte. 14.16.2 Audit-Log: jeder Zugriff auf streng vertrauliche Daten wird protokolliert. 14.16.3 Aufbewahrungspflichten: Lohnabrechnungen 10 Jahre, Verträge 10 Jahre, AU-Bescheinigungen 4 Jahre, Urlaube/Krankmeldungen 4 Jahre. 14.16.4 Bei Mitarbeiter-Austritt: automatische Archivierung mit Hard-Delete-Job nach Aufbewahrungsfrist. 14.16.5 DSGVO-Datenexport: Mitarbeiter kann eigene Daten als ZIP-Paket exportieren.

14.17 Berechtigungen

14.17.1 Geschäftsführung: voller Zugriff (hr.admin). 14.17.2 Vertriebsleitung / Projektleitung: dürfen Anträge ihres Teams genehmigen, Team-Profile sehen. 14.17.3 Backoffice: voller Zugriff auf Lohnabrechnungen, AU-Bescheinigungen, Mitarbeiter-Stammdaten, Bekanntmachungen, Resources. 14.17.4 Vertriebler / Marketing / Monteur: nur eigene Daten (eigenes Profil, eigene Anträge, eigene Krankmeldung, eigene Lohnabrechnungen). 14.17.5 Passwort-Safe-Zugriff zusätzlich pro Vault einzeln freigegeben.

14.18 Phase 2 / bewusst NICHT in Phase 1

14.18.1 Resturlaubs-Tracking (Kontingent-Logik mit Vorjahresübertrag, Stundenkonto). 14.18.2 Zeiterfassung (Stempelfunktion). 14.18.3 Schulungs-Verwaltung mit Wiedervorlage und Ablauf. 14.18.4 Performance-Reviews / Mitarbeitergespräche. 14.18.5 Auto-Chat-Channel pro Standort. 14.18.6 Bulk-Genehmigung für viele Urlaubs-Anträge auf einmal. 14.18.7 Master-Key-Rotation für Passwort-Safe. 14.18.8 Zusatz-Profilseite des Tenants mit „Über uns" / Geschichte / Werten (interne Tenant-Identitäts-Seiten).

14.19 Klartext-Hinweise und Fehlertexte (Beispiele)

14.19.1 Urlaubsantrag erfolgreich: „Dein Urlaubsantrag wurde an [Manager] gesendet. Du erhältst eine Benachrichtigung, sobald entschieden wurde." 14.19.2 Genehmigung: „Dein Urlaub vom [Datum] bis [Datum] wurde genehmigt, Kalender-Eintrag wurde erstellt." 14.19.3 Ablehnung: „Dein Urlaubsantrag wurde abgelehnt. Begründung: [Begründung des Genehmigers]" 14.19.4 Konflikt: „In diesem Zeitraum sind bereits 2 Mitarbeiter im Urlaub (Max M., Lisa K.). Trotzdem genehmigen?" 14.19.5 Lohnabrechnung-Lösch-Versuch: „Lohnabrechnungen sind 10 Jahre aufzubewahren. Stattdessen archivieren?" 14.19.6 Workspace pausiert: „Workspace ist pausiert, neue Anträge nicht möglich."

Modul 15: Customer-Portal (Endkunden-Login)

Was es tut: Ein eigener Login-Bereich für Endkunden des Tenants. Der Endkunde sieht den Status seines Projekts (welche Phase ist gerade dran), kann Dokumente herunterladen (Angebot, Rechnung, Bauabnahme-Protokoll), Dateien hochladen (Reklamations-Fotos, Bauplan-Updates) und über Formulare Reklamationen oder Service-Anfragen einreichen. Löst ab: PlanRadar, Trello-Kunden-Boards, manuelles Mailen von Status-Updates und Dokumenten. Warum es wichtig ist: Kritisch für den Geerkens-Launch (User-Korrektur in der Brainstorming-Session). Endkunde fühlt sich informiert und ruft nicht ständig im Backoffice an.

15.1 Was der Endkunde sieht

15.1.1 Eigene Login-Seite unter app.hivegrid.de/portal/{tenant}/... mit Tenant-Branding (Logo + Farbe). 15.1.2 Dashboard nach Login mit Begrüßung, Übersicht der eigenen Projekte (Anzahl aktiv / abgeschlossen), letzte Status-Änderungen, zuletzt freigegebene Dokumente, Schnell-Funktionen (Datei hochladen, Reklamation melden), Support-Kontakt des Tenants. 15.1.3 Liste der eigenen Projekte mit Titel, aktueller Phase (in Klartext-Bezeichnung, der Tenant entscheidet, wie er die Phasen für den Kunden benennt), Phasen-Fortschritt, Adresse, verantwortlicher Ansprechpartner. 15.1.4 Detail-Sicht eines Projekts: aktuelle Phase mit Fortschritt, Status-Historie (chronologisch), freigegebene Dokumente mit Download, Mängel aus der Bauabnahme falls freigegeben, eigene Reklamations-Formulare, Upload-Funktion, Klick-zum-Mailen an den Projektleiter. 15.1.5 Cross-Projekt-Sicht aller freigegebenen Dokumente mit Filter und Suche. 15.1.6 Eigene Einstellungen: Profil ändern, Passwort setzen/ändern/entfernen, Sprache wechseln, E-Mail-Benachrichtigungen pro Ereignis-Typ konfigurieren, aktive Sessions verwalten, eigene Daten exportieren (DSGVO), Account löschen (DSGVO).

15.2 Welche Phasen sieht der Endkunde

15.2.1 Tenant-Admin entscheidet pro Pipeline, welche Phasen im Portal sichtbar sind, interne Phasen wie „Disposition" oder „Material-Bestellung" bleiben verborgen. 15.2.2 Pro Phase kann der Tenant einen Klartext-Namen für den Kunden vergeben (intern „Materialbeschaffung", für den Kunden „Wir bestellen Ihre Komponenten").

15.3 Was sieht der Endkunde NICHT

15.3.1 Interne Notizen, interne Aktivitäten, interne Kommunikation. 15.3.2 Andere Endkunden des Tenants. 15.3.3 Alle internen Phasen, die nicht ausdrücklich freigegeben wurden. 15.3.4 Mitarbeiter-Daten außer dem zuständigen Ansprechpartner (Projektleiter mit Name, E-Mail, Telefon). 15.3.5 Andere Aufträge oder Deals als die eigenen.

15.4 Datei-Upload durch Endkunde

15.4.1 Endkunde kann Dateien zu seinem Projekt hochladen, z.B. Reklamations-Fotos, neue Baupläne, Anhänge. 15.4.2 Auswahl des Projekts (Dropdown der eigenen Projekte), Kategorie (Reklamation / Foto / Anhang / sonstiges), Beschreibung optional. 15.4.3 Drag-and-Drop und Mehrfach-Upload (max. 10 gleichzeitig). 15.4.4 Mobile-Kamera-Direkt-Upload. 15.4.5 Maximal 50 MB pro Datei (Tenant-konfigurierbar). 15.4.6 Erlaubte Dateitypen: Bilder, PDF, Office-Dokumente, Audio (für Sprach-Notizen). 15.4.7 Upload landet im Projekt-Datei-Bereich des Tenants mit Quelle „Customer-Portal-Upload". 15.4.8 Automatische Push- und E-Mail-Benachrichtigung an den Projektleiter („Kunde X hat Datei Y hochgeladen"). 15.4.9 Bestätigung an den Endkunden („Datei wurde an [Tenant-Name] gesendet, Sie erhalten eine Bestätigung per E-Mail").

15.5 Welche Dokumente werden für den Endkunden freigegeben

15.5.1 Dateien aus dem Projekt sind STANDARDMÄSSIG NICHT für den Endkunden sichtbar, der Tenant gibt explizit frei. 15.5.2 Tenant-Admin kann pro Dokumenten-Typ eine Auto-Freigabe-Regel definieren („alle Angebote auto-freigeben", „alle Rechnungen auto-freigeben", „alle Bauabnahme-PDFs auto-freigeben", „Baupläne auto-freigeben"). 15.5.3 Pro einzelner Datei kann manuell freigegeben oder gesperrt werden, auch für Dateien, die nicht der Auto-Regel entsprechen. 15.5.4 Optional kann der Datei-Name für den Endkunden überschrieben werden (intern „2025-04-19_Geerkens_Angebot_v3_final_REV.pdf", für Endkunde „Ihr Angebot vom 19.04.2025").

15.6 Automatische Status-Mails bei Phasenwechsel

15.6.1 Pro Stage-Wechsel-Ereignis pro Pipeline kann der Tenant entscheiden: Mail an Endkunde ja/nein. 15.6.2 Mail-Vorlage anpassbar mit Platzhaltern (Kunden-Name, Projekt-Titel, neue Phase in Klartext-Bezeichnung, Tenant-Firmenname). 15.6.3 Versand über die Tenant-Absender-Domain. 15.6.4 Mehrere Endkunden pro Projekt (z.B. Bauherr + Architekt) bekommen alle die Mail. 15.6.5 Stage-Wechsel rückwärts: Mail nur, wenn sich der Klartext-Name ändert (kein Spam bei internem Hin-und-Her). 15.6.6 Mehrfach-Wechsel innerhalb 5 Minuten: Debounce, nur die letzte Stage wird gemailt. 15.6.7 Bei neuer Dokumenten-Freigabe: optionale Mail an Endkunde („Neues Dokument verfügbar").

15.7 Reklamations- und Service-Formulare

15.7.1 Tenant-Admin definiert Formulare über Modul 5 mit Subtyp „Portal-Formular". 15.7.2 Endkunde ruft das Formular im Portal auf und füllt es aus. 15.7.3 Submission wird mit Endkunde + Projekt verknüpft, taucht im Activity-Stream des Projekts auf. 15.7.4 Push und E-Mail an den Projektleiter.

15.8 Ein-Weg-Kommunikation in Phase 1 (Anti-Liste)

In Phase 1 ist das Portal bewusst eingeschränkt: 15.8.1 KEIN Chat zwischen Endkunde und Tenant im Portal. 15.8.2 KEINE direkte Mail-Compose im Portal, der Endkunde nutzt seinen normalen Mail-Client über einen Mailto-Link. 15.8.3 KEINE In-App-Notifications im Portal, nur E-Mail-Benachrichtigungen. 15.8.4 KEINE Bidirektionale Kommunikation außer über Formulare und Datei-Uploads. 15.8.5 KEINE Endkunden-Empfehlungs-Programme. 15.8.6 KEINE Wartungs-Abos / Service-Pakete im Portal abschließbar. 15.8.7 KEIN Blog/CMS im Portal. 15.8.8 KEIN Zwei-Faktor-Pflicht für Endkunden (Magic-Link reicht). 15.8.9 KEIN Bulk-Download aller Dokumente als ZIP. 15.8.10 KEIN eigenes Branding pro Portal (in Phase 1 wird das Tenant-Branding genutzt, eigenes Portal-Branding kommt in Phase 2). Phase 1 ist klar: Endkunde sieht Status, lädt Dokumente runter, lädt Dateien hoch, schickt Formulare ab. Mehr nicht. Das ist Absicht, bidirektionale Kommunikation kommt in Phase 2 sauber.

15.9 Auth-Schicht für Endkunden

15.9.1 Endkunden-User sind eine eigene User-Klasse, strikt getrennt von den Tenant-Mitarbeitern. Ein Endkunde kann niemals versehentlich Mitarbeiter-Berechtigungen erlangen. 15.9.2 Login primär über Magic-Link (E-Mail mit zeitlich begrenztem Login-Link, 15 Minuten gültig, einmalig). 15.9.3 Optional setzt der Endkunde ein Passwort (Mindestlänge 12 Zeichen, Prüfung gegen bekannte Passwort-Leaks). 15.9.4 Erst-Login-Setup: Tenant-Mitarbeiter lädt den Endkunden ein → Setup-Mail mit 7-Tage-Token → Endkunde setzt optional Passwort und akzeptiert DSGVO-Hinweise. 15.9.5 Session 30 Tage gleitend, mit Inaktivitäts-Timeout nach 7 Tagen. 15.9.6 Endkunden-Cookies sind klar getrennt von Mitarbeiter-Cookies (eigene Bezeichnung), damit es keine Verwechslung gibt.

15.10 Endkunden-Zugang verwalten (Tenant-Sicht)

15.10.1 Tenant-Admin kann Endkunden auf 4 Wegen einladen: - Direkt aus der Endkunden-Verwaltung. - Aus dem Kontakt-Detail (Daten werden vorausgefüllt). - Aus dem Projekt-Detail (Projekt-Zugang wird automatisch mitgegeben). - Aus dem Deal-Detail (für Pre-Sales-Transparenz, falls aktiviert). 15.10.2 Mehrere Endkunden pro Projekt (Bauherr + Architekt + Ehepartner). 15.10.3 Ein Endkunde kann mehrere Projekte sehen. 15.10.4 Pro Zugang konfigurierbar: voller Lese-Zugriff oder nur Status (ohne Detail/Dokumente). 15.10.5 Tenant-Admin kann Zugang entziehen oder den Endkunden deaktivieren, alle Sessions werden sofort beendet. 15.10.6 Endkunde wird nach Auftragsabschluss NICHT automatisch deaktiviert (Service- und Wartungs-Anfragen weiterhin möglich). 15.10.7 Audit-Log: alle Endkunden-Aktionen (Login, Download, Upload, Formular-Submission) werden protokolliert.

15.11 DSGVO und Lösch-Workflow

15.11.1 Endkunde kann eigenen Account selbst löschen (Multi-Step-Flow mit Passwort-Bestätigung, 24-Stunden-Reverse-Window per Bestätigungs-Mail). 15.11.2 Tenant-Admin kann auch löschen (mit Klartext-Warnung „Hochgeladene Dateien und Formulare bleiben mit anonymisiertem Bezug für Audit-Pflicht"). 15.11.3 Aufbewahrungspflichtige Dokumente bleiben Tenant-seitig (z.B. Acceptance-PDFs). 15.11.4 DSGVO-Datenexport: Endkunde lädt eigene Daten als JSON herunter.

15.12 Tenant-Admin-Konfiguration

15.12.1 Welche Phasen sind sichtbar pro Pipeline (mit Klartext-Namen-Override). 15.12.2 Welche Dokumenten-Typen werden auto-freigegeben. 15.12.3 Welche Auto-Status-Mails werden versendet pro Phasen-Wechsel. 15.12.4 Mail-Vorlagen anpassen (mit Test-Mail an eigene Adresse). 15.12.5 Pflicht-Links für Impressum und Datenschutz (sonst startet das Portal nicht). 15.12.6 Welcome-Message für die Setup-Mail. 15.12.7 Support-E-Mail und Support-Telefon (wird auf Portal-Seiten angezeigt). 15.12.8 Portal aktivieren / deaktivieren (alle Endkunden können dann nicht mehr einloggen, Daten bleiben).

15.13 Portal-Lebensdauer, Skalierung, Subunternehmer-Zugang [N19, 09.05.2026]

Erweiterung gem. Anmerkung Noah, 09.05.2026: Drei Punkte aus der Praxis: (1) Endkunde-Portal endet nicht mit Projektabschluss, sondern bleibt für den Service-Fall offen. (2) Bei großem Kundenbestand braucht der Mandant eine sinnvolle Sicht auf Portal-Aktivität, ohne dass jeder Klick eine Push erzeugt. (3) Bei größeren Projekten arbeiten Subunternehmer und externe Handwerker mit, die ebenfalls projektspezifischen Portal-Zugriff brauchen.

15.13.1 Pro-Kunden-Portal vs. Pro-Projekt-Portal (Lebensdauer)

15.13.1.1 Default-Modus ist Portal pro Kunde, nicht pro Projekt. Ein Endkunde behält seinen Login auch nach Projektabschluss. Service-Anfragen, Reklamationen, Folge-Aufträge laufen über denselben Zugang. 15.13.1.2 Ein Endkunde sieht im Portal eine Liste seiner Projekte (aktive und abgeschlossene), gruppiert nach Status. So bleiben alte Aufträge auffindbar, Dokumente herunterladbar. 15.13.1.3 Pro Mandant umstellbar auf „Pro-Projekt-Portal mit Auto-Schließung nach 12 Monaten" (für Mandanten, die ausdrücklich keinen offenen Service-Kanal wollen). 15.13.1.4 Bei Projektabschluss (Status „abgeschlossen") wird der Endkunde mit einer Klartext-Mail informiert: „Ihr Projekt [Titel] ist abgeschlossen. Ihr Zugang bleibt für Service- und Wartungs-Anfragen weiterhin aktiv. [Portal öffnen]". 15.13.1.5 Endkunden-Konten ohne Aktivität für 24 Monate werden auto-deaktiviert mit Vorwarn-Mail (Mandant kann Schwellenwert anpassen).

15.13.2 Skalierungs-Sicht: Portal-Aktivität bei vielen Endkunden

15.13.2.1 Mandanten mit hunderten oder tausenden aktiven Endkunden brauchen eine Aggregations-Sicht statt einzelner Push-Benachrichtigungen pro Aktivität. 15.13.2.2 Service-Inbox im Mandanten (neue Sicht in der HiveGrid-App): zeigt alle Endkunden-Aktivitäten der letzten 7 Tage in einer einheitlichen Liste, sortiert nach Priorität (Reklamation > Datei-Upload > Login > Download). 15.13.2.3 Pro Eintrag: Kunde, Projekt, Aktivitäts-Typ, Zeitpunkt, Status (offen / in Bearbeitung / erledigt), Verantwortlicher. 15.13.2.4 Routing-Regeln für Endkunden-Aktivitäten (analog Lead-Routing in M02): pro Aktivitäts-Typ definiert der Mandant, wer benachrichtigt wird (z. B. Reklamationen → Service-Team, Datei-Uploads → Projektleiter des Projekts, allgemeine Logins → keine Notification). 15.13.2.5 Anti-Spam-Bündelung (siehe Modul 22): mehrere Aktivitäten desselben Endkunden in 30 Minuten werden zu einer Push gebündelt („Müller hat 5 Dateien hochgeladen und 1 Reklamation eingereicht"). 15.13.2.6 Service-Team-Default-Rolle: für Mandanten mit großer Kundenbasis empfehlen wir eine eigene Rolle „Service-Team", die Lese-Zugriff auf alle Portal-Aktivitäten hat ohne Vertriebs-Zugriff (siehe M27.7). 15.13.2.7 Stille Modi: pro Endkunde-Aktivitäts-Typ konfigurierbar „nur in Service-Inbox sammeln, keine Push" — verhindert Notification-Müdigkeit bei großen Kundenbeständen.

15.13.3 Subunternehmer und externe Handwerker im Projekt-Portal

15.13.3.1 Anwendungsfall: bei größeren Projekten (z. B. Mehrfamilienhaus-Sanierung) sind neben dem Endkunden auch externe Handwerker, Architekten oder Subunternehmer am Projekt beteiligt. Sie brauchen eingeschränkten Portal-Zugriff für Datei-Austausch und Status-Sicht. 15.13.3.2 Subunternehmer-Konten sind eine eigene Untergruppe der Endkunden-User-Klasse (technisch gleich, fachlich getrennt). Sie haben einen Hinweis-Badge „Subunternehmer" oder „Externer Handwerker" im Portal sichtbar. 15.13.3.3 Pro Projekt kann der Mandant eine Liste von Subunternehmern führen mit: Firmen-Name, Ansprechpartner, Email, Rolle im Projekt (z. B. „Elektriker", „Sanitär-Meister", „Statiker"), Zeitraum der Beteiligung. 15.13.3.4 Sichtbarkeit pro Subunternehmer-Zugang konfigurierbar: - welche Phasen des Projekts werden angezeigt; - welche Dokumente sind freigegeben (Subunternehmer sieht z. B. nur Baupläne, nicht das Angebot); - sieht er andere Subunternehmer? (Standard: ja, damit sie sich abstimmen können). 15.13.3.5 Datei-Upload durch Subunternehmer ist möglich (z. B. eigene Mess-Berichte, Fotos vom Gewerk-Stand) und wird mit Quelle „Subunternehmer [Name]" gekennzeichnet. 15.13.3.6 Subunternehmer sehen den Endkunden NICHT (kein Datenleck zwischen externen Beteiligten und Endkunde). 15.13.3.7 Audit-Log protokolliert jede Subunternehmer-Aktivität separat. 15.13.3.8 Skalierung mehrere Projekte: ein Subunternehmer kann in mehreren Projekten desselben Mandanten aktiv sein, mit derselben Login-Identität, aber pro Projekt unterschiedlicher Sichtbarkeit. 15.13.3.9 Phase-2-Erweiterung: Subunternehmer-Liste mit Bewertungen, Verfügbarkeits-Anfragen, Auftrags-Vergabe als eigenes Sub-Modul. Phase 1 nur Portal-Zugriff.

15.14 Phase 2 / bewusst NICHT in Phase 1

15.14.1 Bidirektionale Kommunikation (Chat zwischen Endkunde und Tenant). 15.14.2 Eigenes Portal-Branding (Logo + Farben + eigene Domain kunden.geerkens.de). 15.14.3 Mehrere Portale pro Tenant (Privatkunden vs. Bauträger). 15.14.4 Wartungs-Abos / Service-Pakete im Portal abschließbar mit Legacy-Provider. 15.14.5 Blog/CMS für redaktionelle Inhalte (Wartungs-Tipps, News). 15.14.6 Push-Notifications über installierbare PWA. 15.14.7 Auto-Deaktivierung nach X Tagen ohne Login. 15.14.8 Direkte Mail-Compose im Portal. 15.14.9 Endkunden-Empfehlungs-/Referral-Programm. 15.14.10 Portal-Analytics (welche Endkunden sind aktiv, welche Dokumente werden geöffnet). 15.14.11 Subunternehmer-Liste mit Bewertungen und Auftrags-Vergabe als eigenes Sub-Modul (siehe 15.13.3.9).

15.15 Klartext-Hinweise und Fehlertexte (Beispiele)

15.15.1 Login: „Wir haben Ihnen einen Login-Link an [E-Mail] gesendet. Der Link ist 15 Minuten gültig." 15.15.2 Setup: „Willkommen bei [Tenant-Name]. Bitte vervollständigen Sie Ihr Profil, um auf Ihre Projekte zuzugreifen." 15.15.3 Leeres Projekt-Detail: „Aktuelle Phase: [Phase]. Es gibt noch keine freigegebenen Dokumente. Sie werden per E-Mail informiert, sobald sich der Status ändert." 15.15.4 Workspace pausiert: „Aktuell sind keine Uploads möglich. Bei Fragen wenden Sie sich an [Support]." 15.15.5 Datei zu groß: „Die Datei ist größer als das erlaubte Maximum von 50 MB. Bitte komprimieren oder in mehrere Dateien aufteilen." 15.15.6 Unbekannter Dateityp: „Dieser Dateityp ist nicht erlaubt. Erlaubte Typen: [Liste]." 15.15.7 Tenant gekündigt: „Dieser Anbieter hat sein Konto gekündigt. Daten werden am [Datum] gelöscht." 15.15.8 Subunternehmer-Hinweis: „Sie sehen dieses Projekt als Subunternehmer ‚[Firma]'. Endkunden-Daten und Angebot sind für Sie nicht freigegeben."

Modul 20: Geschäftsführer-Dashboard

Was es tut: Aggregierte Kennzahlen aus allen Modulen, zusammengestellt zu rollen-spezifischen Übersichten. Standard-Layouts pro Rolle (Geschäftsführer, Vertriebsleiter, Vertriebler, Projektleiter, Backoffice, Marketing, Monteur), die jeder Mitarbeiter selbst anpassen darf. Klick auf eine Kennzahl öffnet die zugrunde liegende Liste (Drill-Down), das ist die Kern-Anforderung. Löst ab: Excel-Reports, manuelle Auswertungen am Monatsende, Power-BI-Mini-Setups. Warum es wichtig ist: Der Geschäftsführer (Noah) muss nach dem Login in 30 Sekunden wissen, wo der Betrieb steht, Forecast, Pipeline, Auslastung, KWP-Sync-Status, offene Mängel. Das Dashboard ist das erste, was er sieht.

20.1 Welche Kennzahlen (Widgets) gibt es

Aus den verschiedenen Modulen werden Kennzahlen-Bausteine zusammengestellt, der Tenant sucht aus dem Katalog aus, was er sehen will: 20.1.1 Sales-Kennzahlen aus Modul 3: - Pipeline-Übersicht (Anzahl Deals pro Stage, Aggregat-Volumen). - Deal-Trend über Zeit. - Umsatz-Forecast (Volumen × Wahrscheinlichkeit). - Vertriebler-Performance (pro Vertriebler: Anzahl Deals, Volumen, Win-Rate, Aktivitäts-Kennzahlen). - Verlust-Gründe (warum Deals verloren gehen). - Stage-Conversion (wie viel Prozent gehen von Stage A nach Stage B). - Eigene offene Deals (für den einzelnen Vertriebler). 20.1.2 Projekt-Kennzahlen aus Modul 4: - Projekt-Pipeline-Übersicht. - Status-Verteilung der Projekte. - Mitarbeiter-Auslastung (aus der Plantafel). - Offene Mängel aus den Bauabnahmen. - Eigene aktive Projekte (für den einzelnen Projektleiter). 20.1.3 Aufgaben-Kennzahlen aus Modul 26: - Eigene offene Aufgaben (heute / diese Woche / überfällig). - Team-Erledigungsrate. 20.1.4 Activity-Kennzahlen aus Modul 1: - Eigene letzte Aktivitäten. - Team-Aktivitäten chronologisch. 20.1.5 Kommunikations-Kennzahlen aus Modul 9 und 12: - Anzahl ungelesener Mails. - Anzahl Anrufe heute. 20.1.6 Allgemein: - Begrüßung („Guten Morgen, Noah!"). - KWP-Sync-Status (letzter Sync, Erfolgs-Status). - Tenant-Health (Subscription-Status, Nutzung). 20.1.7 HR-Kennzahlen aus Modul 14: - Wer ist heute da / im Urlaub / krank. - Offene Genehmigungs-Anträge. 20.1.8 KI-Kennzahlen aus Modul 18: - KI-Vorschläge basierend auf Tenant-Kontext.

20.2 Pipeline-Forecast (Sales-Vorhersage)

20.2.1 Pro Deal in der Pipeline ist eine Win-Wahrscheinlichkeit hinterlegt (kommt aus der Stage-Konfiguration in Modul 3 oder wird manuell pro Deal überschrieben). 20.2.2 Forecast = Summe (Deal-Volumen × Win-Wahrscheinlichkeit) über alle aktiven Deals in einem Zeitraum. 20.2.3 Filter pro Zeitraum (nächste 30 / 60 / 90 Tage), pro Vertriebler, pro Pipeline. 20.2.4 Vergleich zum Vormonat / Vorjahr. 20.2.5 Klick auf den Forecast-Wert öffnet die zugrunde liegende Deal-Liste mit allen einbezogenen Deals, der Geschäftsführer kann nachvollziehen, welche Deals den Forecast treiben.

20.3 Vertriebler-Performance

20.3.1 Pro Vertriebler in einer Tabelle: Anzahl Deals (Open/Won/Lost), Gesamt-Volumen, durchschnittliche Deal-Dauer, Win-Rate, Aktivitäts-Kennzahlen (Anzahl Calls, Mails, Termine). 20.3.2 Sortierbar nach jeder Spalte. 20.3.3 Zeitraum konfigurierbar (dieser Monat / Quartal / Jahr). 20.3.4 Klick auf den Vertriebler-Namen öffnet dessen eigene Deal-Liste. 20.3.5 Klick auf eine Kennzahl (z.B. Won-Rate) öffnet die Liste der dazu passenden Deals.

20.4 Drill-Down zu Detail-Listen: die Kern-Anforderung

Das ist das Herzstück: 20.4.1 Jede Kennzahl ist klickbar. 20.4.2 Klick öffnet die zugrunde liegende Liste mit allen Datensätzen, die in die Kennzahl einfließen, vorgefiltert mit den gleichen Bedingungen, die das Widget verwendet hat. 20.4.3 Beispiele: - „47 offene Deals" → klick → Deal-Liste mit 47 Deals, gefiltert nach „offen". - „Offene Mängel: 12" → klick → Mängel-Liste mit 12 Einträgen. - „Heute krank: 3 Mitarbeiter" → klick → Liste der 3 Krankmeldungen. - „Forecast 60.000 €" → klick → Liste der einbezogenen Deals mit Volumen und Wahrscheinlichkeit. 20.4.4 Drill-Down respektiert die Berechtigungen, der Vertriebler sieht beim Drill-Down auf „eigene Deals" nur seine eigenen, der Geschäftsführer alles. 20.4.5 Aus der Drill-Down-Liste kann er direkt zur Detail-Sicht eines Datensatzes navigieren.

20.5 Standard-Layouts pro Rolle

Beim Anlegen eines neuen Tenants werden 7 Standard-Dashboards vorinstalliert: 20.5.1 Geschäftsführer-Dashboard: - Begrüßung, Pipeline-Kennzahlen, Forecast 3 Monate, Vertriebler-Performance, Projekt-Pipeline, Auslastung, offene Mängel, KWP-Sync-Status, Tenant-Health, HR „wer ist heute da". - Das ist Noahs Default-Sicht. 20.5.2 Vertriebsleitung: - Begrüßung, Pipeline-Kennzahlen, Deal-Trend, Vertriebler-Performance, Verlust-Gründe, Stage-Conversion, Team-Aufgaben-Erledigungsrate. 20.5.3 Vertriebler: - Begrüßung, eigene offene Deals, eigene Aufgaben, ungelesene Mails, Anrufe heute, eigene letzte Aktivitäten. 20.5.4 Projektleitung / Bauleitung: - Begrüßung, eigene aktive Projekte, eigene offene Mängel, Auslastung des eigenen Teams, eigene Aufgaben, HR „wer ist heute da". 20.5.5 Backoffice: - Begrüßung, Projekt-Pipeline, eigene Aufgaben, ungelesene Mails, offene HR-Anträge, KWP-Sync-Status. 20.5.6 Marketing: - Begrüßung, Deal-Trend, Verlust-Gründe, Stage-Conversion. 20.5.7 Monteur (Mobile-First): - Eigene Termine heute, eigene aktive Projekte, eigene Aufgaben, optional KI-Walkthrough-Hinweise.

20.6 Eigenes Layout anpassen (User-Customizing)

20.6.1 Jeder Mitarbeiter darf sein eigenes Layout anpassen (Drag-and-Drop-Grid). 20.6.2 Widgets aus dem Katalog hinzufügen (nur die, für die er Berechtigungen hat, Vertriebler sieht z.B. nicht „HR offene Anträge" im Katalog). 20.6.3 Widgets verschieben, vergrößern, verkleinern, löschen. 20.6.4 Pro Widget eigene Konfiguration (Zeitraum-Filter, Stage-Filter etc.). 20.6.5 „Reset auf Standard", zurück zum Rollen-Default mit Klartext-Bestätigung („Dein angepasstes Layout wird durch das Standard-Layout deiner Rolle ersetzt"). 20.6.6 Geschäftsführung kann die Standard-Layouts pro Rolle Tenant-weit anpassen.

20.7 Performance und Live-Updates

20.7.1 Kennzahlen werden serverseitig berechnet und mit kurzem Cache (60 Sekunden Standard) ausgeliefert, die Geschäftsführung lädt das Dashboard nicht neu, weil die Datenbank schwitzt. 20.7.2 Bei großen Datenmengen: vorab berechnete Aggregate, die nachts via Cron erneuert werden. 20.7.3 Live-Updates über WebSocket bei wichtigen Ereignissen (Deal gewonnen, neuer Lead, Mängel-Acceptance), sanfte Animation, damit der Geschäftsführer die Änderung sieht. 20.7.4 Opt-Out pro User („Live-Updates pausieren") für ungestörtes Arbeiten. 20.7.5 Lazy Loading: nur sichtbare Widgets werden geladen, der Rest erst beim Scrollen. 20.7.6 Klartext-Hinweis bei veralteten Daten: „Daten zuletzt aktualisiert vor X Minuten."

20.8 Berechtigungen

20.8.1 Jedes Widget zeigt nur Daten, für die der eingeloggte Mitarbeiter Berechtigungen hat, Vertriebler sieht keine Vertriebler-Performance der ganzen Mannschaft, sondern nur seine eigene. 20.8.2 Widgets ohne Berechtigung werden im Katalog ausgegraut mit Klartext „Hierfür benötigst du erweiterte Berechtigungen". 20.8.3 Bei Rollen-Wechsel mit verlorenen Berechtigungen werden die betroffenen Widgets ausgeblendet.

20.9 Phase 2 / bewusst NICHT in Phase 1

20.9.1 Eigene Widgets per Formel-Editor („KPI-Studio", der Tenant baut sich eigene Widgets aus beliebigen Datenquellen). 20.9.2 Geplante Reports per E-Mail (z.B. wöchentlicher Pipeline-Bericht automatisch montags). 20.9.3 Public-Dashboards (extern teilbar, z.B. für externe Berater). 20.9.4 Erweiterte Visualisierungen (heatmaps, geographische Karten, Sankey-Diagramme). 20.9.5 KI-gestützte Anomalie-Erkennung („Win-Rate diesen Monat 20% unter Schnitt, soll ich nachforschen?").

20.10 Klartext-Hinweise (Beispiele)

20.10.1 Widget-Ladefehler: „Daten konnten gerade nicht geladen werden, erneut versuchen." 20.10.2 Widget ohne Daten: „Noch keine Daten, sobald [Modul] genutzt wird, erscheinen hier die Kennzahlen." 20.10.3 Veraltete Daten: „Daten zuletzt aktualisiert vor 12 Minuten." 20.10.4 Layout-Reset: „Dein angepasstes Layout wird durch das Standard-Layout deiner Rolle ersetzt."

Block 7: Plattform-Außenseite (Betrieb, Compliance, Zugang)

Acht Module, die HiveGrid als bezahlbares, regelkonformes und sicher betreibbares Produkt machen: das Audit-Log für Nachvollziehbarkeit, Legacy-Provider-basierte Abrechnung, Onboarding für neue Mandanten, eine Lese-API mit Webhooks für Drittanbieter, der DSGVO-Export, die Mobile-App auf Capacitor-Basis, das öffentliche Hilfe-Center und der interne Help-Desk.

Modul 21: Audit-Log

Was es tut: Schreibt für jeden Mandanten einen lückenlosen Verlauf aller verändernden Aktionen mit Vorher-/Nachher-Vergleich mit. Macht nachvollziehbar, wer wann was geändert hat, von Mitarbeitern, Automationen, KI oder externen Schnittstellen.

Warum es wichtig ist: Pflicht für DSGVO-Auskünfte, interne Kontrolle, Sicherheits-Forensik und Streitfälle vor Gericht. Ohne Audit-Log kann der Betrieb im Zweifelsfall nicht beweisen, was passiert ist.

21.1 Was wird protokolliert

21.1.1 Jede schreibende Aktion in jedem Modul erzeugt einen Audit-Eintrag, Pflicht-Vorschrift, kein Modul ist befreit. 21.1.2 Erfasste Bereiche umfassen: Anmeldungen und Abmeldungen, Passwort- und 2FA-Änderungen, Einladungen, Rollen- und Rechtevergabe, Anlegen/Ändern/Löschen von Kontakten, Firmen, Leads, Deals, Projekten, Aufgaben, das Versenden von E-Mails und Marketing-Kampagnen, Telefonate, Datei-Uploads, Anlegen und Aktivieren von Automationen, KI-Aktionen, Änderungen an Einstellungen und Integrationen sowie das Anlegen oder Widerrufen von API-Schlüsseln. 21.1.3 Das Audit-Log loggt sich selbst, Exporte, das Setzen eines Legal Hold (siehe 21.4) und Änderungen an der Aufbewahrungsdauer werden ebenfalls erfasst. 21.1.4 Bewusst NICHT erfasst: reine Lese-Aktionen (Liste anschauen, Detail öffnen), häufige Bearbeitungen wie Chat-Nachrichten-Edits sowie der Lese-Status von Benachrichtigungen, sonst würde das Log überflutet. 21.1.5 Sensible Lese-Vorgänge (HR-Daten lesen, DSGVO-Export herunterladen) werden trotzdem erfasst. 21.1.6 Pro Eintrag werden u.a. erfasst: Datum/Uhrzeit, ausführende Person bzw. System (Mitarbeiter, Automation, KI, API-Schlüssel, Plattform-Admin), betroffenes Objekt, Kurzbeschreibung in Klartext-Deutsch, IP-Adresse und Browser-Kennung bei Mitarbeiter-Aktionen.

21.2 Diff-Anzeige

21.2.1 Jeder Eintrag zeigt im Detail Vorher- und Nachher-Stand der geänderten Felder. 21.2.2 Bei einfachen Werten direkt nebeneinander, bei verschachtelten Daten als strukturierter Vergleich (Hinzufügungen, Löschungen, Änderungen). 21.2.3 Sensible Felder (Passwörter, Geheimnisse) werden nicht im Klartext angezeigt, nur die Information „Wert wurde geändert". 21.2.4 Bei einer Massen-Aktion (z.B. 50 Kontakte gleichzeitig getaggt) wird ein Sammel-Eintrag plus die Einzeleinträge gezeigt; auf Klick aufklappbar. 21.2.5 Wenn das betroffene Objekt inzwischen gelöscht ist, wird der gespeicherte Name als Klartext-Snapshot angezeigt. 21.2.6 Bei Aktionen aus Automation oder KI: Verlinkung zur ausführenden Automation bzw. zum KI-Prompt.

21.3 Filter und Suche

21.3.1 Pflicht-Filter (immer sichtbar): Zeitraum (Default: letzte 30 Tage), Akteur (Mehrfachauswahl: einzelne Mitarbeiter, System, Automation, KI, API-Schlüssel), Aktions-Kategorie gruppiert (Anmeldung, CRM, Projekte, Kommunikation, Einstellungen). 21.3.2 Erweiterte Filter: Objekt-Typ, IP-Adresse (Sicherheits-Forensik), Akteur-Art, Bulk-Operation-ID, Request-ID (für Support-Korrelation). 21.3.3 Volltext-Suche über die Klartext-Zusammenfassung jedes Eintrags. 21.3.4 Mitarbeiter können Filter-Kombinationen als „Gespeicherte Ansicht" speichern (max. 5 pro Person). 21.3.5 Vorgefertigte Default-Ansichten: „Anmelde-Aktivität letzte 7 Tage", „Rechte-Änderungen letzte 30 Tage", „Endgültige Löschungen letzte 90 Tage", „API-Schlüssel-Aktionen". 21.3.6 In jedem Detail-Bildschirm (Kontakt, Deal, Projekt) gibt es eine Audit-Schublade, die die Aktionen genau dieses Objekts zeigt, sichtbar für Personen mit Audit-Leserecht.

21.4 Aufbewahrungsfristen (24 Monate)

21.4.1 Default-Aufbewahrung: 24 Monate ab Erfassung. 21.4.2 Der Mandanten-Admin kann die Frist anpassen, minimal 6 Monate, maximal 120 Monate. 21.4.3 Ein täglicher automatischer Lösch-Job räumt ältere Einträge ab, außer es ist ein „Legal Hold" gesetzt. 21.4.4 Legal Hold = Pause der automatischen Löschung für den gesamten Mandanten, z.B. bei Rechtsstreit oder Behörden-Anforderung. Setzen erfordert Pflicht-Begründung (mind. 20 Zeichen Freitext) und ist nur dem Mandanten-Admin mit Audit-Admin-Recht erlaubt. 21.4.5 Bei Reduzierung der Aufbewahrungsfrist erscheint Klartext-Bestätigung: „Wenn du die Frist auf 12 Monate setzt, werden ca. X Audit-Einträge älter als 12 Monate beim nächsten automatischen Lauf entfernt." 21.4.6 Die Audit-Tabelle ist technisch gegen nachträgliche Änderungen geschützt, auch der Plattform-Anbieter kann Einträge nicht editieren (nur das automatische Lösch-Programm darf gemäß Frist entfernen).

21.5 Compliance-Export

21.5.1 Ein Export-Job kann mit identischen Filtern wie die Listen-Ansicht angelegt werden, Format wählbar (CSV, JSON, PDF). 21.5.2 Pflicht-Eingabe: Zweck-Begründung (Freitext), wird selbst geloggt. 21.5.3 Vor Submit: Vorschau der zu exportierenden Anzahl Einträge. 21.5.4 Verarbeitung asynchron, Benachrichtigung bei Fertigstellung. 21.5.5 Download-Link gültig 7 Tage; danach wird die Export-Datei automatisch gelöscht. 21.5.6 Jeder Export wird selbst auditiert und ist sichtbar für andere Mandanten-Admins (kein blinder Fleck).

21.6 Berechtigungen

21.6.1 Recht „Audit lesen", Audit-Trail einsehen, Detail, Filter, Suche. 21.6.2 Recht „Audit administrieren", Exporte anlegen, Aufbewahrungsfristen ändern, Legal Hold setzen. 21.6.3 HR-Audit-Diffs voll sichtbar nur mit zusätzlichem HR-Vollleserecht oder Audit-Admin. 21.6.4 Mandanten-Daten sind strikt getrennt, keine Cross-Mandanten-Sicht außer für Plattform-Admin (mit eigenem Audit).

21.7 Phase 2 / bewusst NICHT in Phase 1

21.7.1 Hash-Kette für nachweisbare Manipulations-Sicherheit (jeder Eintrag verkettet kryptografisch mit dem vorherigen). 21.7.2 Externes Zeitstempeln über RFC-3161-EU-Provider. 21.7.3 PDF-Bericht mit digitaler Signatur via PandaDoc. 21.7.4 KI-basierte Anomalie-Erkennung (verdächtige Login-Zeiten, Massen-Lösch-Aktionen, Rechte-Eskalation). 21.7.5 Live-Feed (Server-Sent-Events) für Mandanten-Admin-Echtzeit-Monitoring. 21.7.6 Self-Audit für jeden Mitarbeiter (eigene Aktivitäten der letzten 90 Tage in Kontoeinstellungen).

21.8 Klartext-Fehlertexte (Beispiele)

21.8.1 Leerer Trail (frischer Mandant): „Noch keine Aktionen erfasst, Audit-Einträge erscheinen, sobald jemand schreibend tätig wird." 21.8.2 Filter ohne Treffer: „Keine Einträge passen zu deinen Filtern. [Filter zurücksetzen]" 21.8.3 Gelöschtes Objekt: „Das betroffene Objekt wurde inzwischen gelöscht. Snapshot-Name: ‚X'." 21.8.4 Sensibler Diff: „Aus Datenschutz-Gründen wird nur ‚Wert geändert' angezeigt." 21.8.5 Legal Hold aktiv: „Legal Hold aktiv seit [Datum], keine automatische Löschung. Begründung: [Text]. [Bei Bedarf aufheben]" 21.8.6 Ohne Audit-Recht: „Du hast keine Berechtigung, das Audit-Log zu sehen. Bitte Mandanten-Admin kontaktieren."

Modul 28: Subscriptions / Billing

Was es tut: Verbindet HiveGrid mit Legacy-Provider als Bezahl-Anbieter und steuert den gesamten Abo-Lebenszyklus jedes Mandanten, vom Trial über aktive Bezahlung, Pausen, Mahnwesen bis zur Kündigung. Zählt Sitzplätze (Büro vs. Monteur) und nutzungsbasierten Verbrauch (Automationen, KI-Verbrauch).

Warum es wichtig ist: Ohne stabile, regelkonforme Abrechnung verdient die Plattform kein Geld. Die Mechanik muss flexibel genug sein, dass Preise später angepasst werden können, ohne den Code zu ändern. Apple-Compliance (siehe 28.X) ist dabei ein hartes Tabu, das die ganze Architektur prägt.

28.1 Bezahl-Anbieter Legacy-Provider

28.1.1 Legacy-Provider ist exklusiver Bezahl-Anbieter in Phase 1, Vertragspartner ist die EU-Tochter Legacy-Provider Payments Europe (Irland), DSGVO-Auftragsverarbeitungsvertrag elektronisch unterzeichnet beim Signup. 28.1.2 Steuern werden über Legacy-Provider Tax mit EU-Reverse-Charge-Logik abgewickelt. 28.1.3 Zahlungsarten in Phase 1: SEPA-Lastschrift (Default Deutschland/EU) und Kreditkarte. 28.1.4 Legacy-Provider sendet Ereignisse (Webhooks) an HiveGrid: erfolgreicher Bezahlvorgang, Rechnung erstellt, Zahlung gescheitert, Plan geändert, Subscription gelöscht, Trial-Ende-Vorwarnung. 28.1.5 Jedes Legacy-Provider-Ereignis wird genau einmal verarbeitet (Doppel-Schutz über eindeutige Legacy-Provider-Event-Kennung). 28.1.6 Plan-Konfiguration ist nicht im Code festgenagelt, sondern in Daten-Strukturen, neue Pläne, Preise und Quotas sind ohne Code-Release änderbar.

28.2 Seat-Modell (Büro/Monteur)

28.2.1 Zwei Sitzplatz-Typen, gespiegelt zur Leitplanke „Büro vs. Baustelle als zwei Erlebnisse": - Büro-Sitzplatz: Vollzugang, Default-Modus „Büro", alle Module gemäß Rechten. - Monteur-Sitzplatz: eingeschränkter Zugang, Default-Modus „Baustelle", reduzierte Modul-Sicht (Projekt-Detail, Aufgaben, Acceptance, Foto-Forms, Chat in eigenen Räumen, eigene HR-Dokumente). 28.2.2 Bei jeder Mitarbeiter-Einladung wählt der Mandanten-Admin den Sitzplatz-Typ, Pflichtfeld. 28.2.3 Sitzplatz-Typ ist Lizenz-Konzept, Rolle ist Rechte-Konzept, getrennt. 28.2.4 Monteur-Sitzplatz darf nur Rollen mit Default-Modus „Baustelle" bekommen (Validierungs-Regel). 28.2.5 Sitzplatz-Zähler werden bei jeder Einladung/Aktivierung/Deaktivierung mit Legacy-Provider synchronisiert. 28.2.6 Plan-Quotas (z.B. „max. 10 Büro-Sitzplätze, max. 50 Monteur-Sitzplätze") sind pro Plan konfigurierbar. 28.2.7 Quota-Verhalten: Default „Hartes Limit", neue Einladung blockiert mit Klartext-Hinweis. Optional „weiches Limit", zusätzliche Sitzplätze werden automatisch nutzungsbasiert abgerechnet. 28.2.8 Verbrauchs-Übersicht im Mandanten-Admin zeigt aktuelle Sitzplätze pro Typ, verfügbare Sitzplätze laut Plan, Trend-Chart.

28.3 Trial-Phase

28.3.1 Trial-Dauer 5–7 Tage pro Plan konfigurierbar. 28.3.2 In Phase 1 nur Vertriebs-freigegebene Trials, der Vertrieb (Plattform-Admin) muss den Trial manuell aktivieren, um Spam-Anmeldungen zu verhindern. 28.3.3 Voller Funktionsumfang während Trial, kein Read-Only. 28.3.4 Zahlungsmethode ist im Vertriebs-Modus nicht zwingend zu Trial-Beginn. 28.3.5 3 Tage und 1 Tag vor Trial-Ende: In-App-Banner und E-Mail-Benachrichtigung mit Klartext-Hinweis und Verweis auf Marketing-Site (NICHT auf In-App-Upgrade, siehe Apple-Compliance 28.X). 28.3.6 Trial-Ende ohne Konversion: Mandant geht in 30-Tage-Lösch-Vorlauf (siehe Modul 35.6). 28.3.7 Trial-Konversion läuft über Marketing-Site, von dort zurück in die App mit Legacy-Provider-Session-Token.

28.4 Read-Only-Downgrade bei Nichtzahlung

28.4.1 Wenn der Mandant nicht bezahlt, kann er nur noch ansehen, nichts mehr ändern, bis er bezahlt, das ist die Klartext-Idee dahinter. 28.4.2 Auslöser: Legacy-Provider meldet Zahlung gescheitert. 28.4.3 Legacy-Provider-Standard-Mahnwesen: 3 automatische Wiederholungs-Versuche über 14 Tage (typisch Tag 0, 3, 7, 14). 28.4.4 Während Mahnwesen wechselt der Mandant in den Status „Zahlung überfällig" → kompletter Workspace ist Read-Only: - Anmeldung, Daten lesen, Kunden-Portal-Zugang (Endkunden) und Legacy-Provider-Kunden-Portal-Zugang bleiben möglich. - Stammdaten-Edits, neue Datensätze, E-Mail-/WhatsApp-/Push-Versand, Automationen-Ausführung, eingehende Webhooks und API-Schreiboperationen sind blockiert. - Eingehende Trigger werden verworfen (nicht in Warteschlange), sonst stauen sich Aktionen auf, die mit gepausten Zahlungen kollidieren. 28.4.5 Klartext-Banner: „Zahlung fehlgeschlagen, Konto in 14 Tagen gesperrt, [Zahlungsmethode aktualisieren]" mit Direkt-Link zum Legacy-Provider-Kunden-Portal. 28.4.6 E-Mail-Benachrichtigungen an Mandanten-Admins bei jedem Zustand: erste Zahlung gescheitert, 2. Versuch gescheitert, 1 Tag vor finalem Cancel. 28.4.7 Nach 3 Fehlversuchen + 14 Tagen ohne Erfolg: Status wechselt auf „gekündigt". 28.4.8 Sobald Zahlung nachgereicht: automatischer Wechsel zurück auf „aktiv".

28.5 Frozen-Modus (User-Pause)

28.5.1 Der Mandant kann seinen Workspace freiwillig pausieren statt zu kündigen, gedacht für Saison-Pausen kleiner Betriebe. 28.5.2 Reduzierte Gebühr (Default ca. 1/10 des Standardpreises, exakte Werte gehören in die Pricing-Festlegung), Workspace Read-Only, jederzeit reaktivierbar, Daten bleiben erhalten. 28.5.3 Pause-Bestätigung erfordert Eingabe der Phrase „PAUSIEREN" als Schutz gegen Versehen. 28.5.4 Reaktivierung über Bezahl-Vorgang in Legacy-Provider.

28.6 Rechnungsstellung

28.6.1 Rechnungs-Übersicht im Mandanten-Admin als Legacy-Provider-Kunden-Portal eingebettet (von Legacy-Provider gehostet). 28.6.2 Funktionen dort: Rechnungs-Historie als PDF herunterladen, Zahlungsmethode aktualisieren, Steuer-Daten/USt-IdNr. editieren. 28.6.3 Rechnungen werden in HiveGrid als Referenz gespiegelt; Original-Dateien lädt der User aus Legacy-Provider.

28.7 Setup-Gebühren

28.7.1 Pro Plan optional eine einmalige Setup-Gebühr. 28.7.2 Im Legacy-Provider-Bezahlvorgang erscheinen zwei Posten, wiederkehrender Plan-Preis plus einmalige Setup-Gebühr. 28.7.3 Bei Plan-Wechsel zu höherem Plan wird nur die Differenz der Setup-Gebühr berechnet. 28.7.4 Klartext-Hinweis im Bezahlvorgang: „Bei Buchung wird zusätzlich eine einmalige Setup-Gebühr von [Betrag] berechnet."

28.8 Verbrauchs-Erfassung (Automationen, KI) [N13, 09.05.2026]

28.8.1 Erfasst werden: Anzahl Automation-Trigger pro Periode, KI-Verbrauch (normalisiert über Provider). 28.8.2 Pro Plan ein Inklusiv-Volumen plus Aufschlags-Tarif für Mehrverbrauch (Pay-as-you-go). KI-Funktionen werden NICHT pausiert (siehe M18.8). Konkrete Schwellen und Stückpreise mit Pricing-Festlegung (geparkt, siehe H.1.1). 28.8.3 Verbrauchs-Sicht im Mandanten-Admin: aktuelle Periode, Inklusiv-Menge, Verbrauch in Prozent, Trend, Historie der letzten 12 Perioden, aktueller Aufschlags-Verbrauch in Euro, voraussichtlicher Monats-Aufschlag, CSV-Export. 28.8.4 KI-Inklusiv-Menge verfällt am Periodenende. Manuelle Boni vom Vertrieb bleiben. 28.8.5 Aufschlags-Verbrauch wird pro Legacy-Provider-Rechnungs-Periode als separate Position ausgewiesen (Detail-Aufschlüsselung pro KI-Funktion und Tag). 28.8.6 Notbremse: pro Mandant konfigurierbar, max. Aufschlags-Betrag pro Monat. Bei Erreichen wird in Drosselungs-Modus geschaltet (nur Klartext-Diagnostik bleibt aktiv), nicht in Komplett-Pause. Klartext-Warnung an Administrator (siehe M18.8.7). 28.8.7 Upsell-Vorschlag: wenn Aufschlag in 2 aufeinanderfolgenden Monaten höher liegt als die Differenz zum nächsten Plan, schlägt das System aktiv ein Upgrade vor. Soft-Recommendation, kein Zwang. 28.8.8 Bei aufgebrauchtem Inklusiv-Volumen: Klartext im Banner: „Inklusiv-Volumen verbraucht, weitere Anfragen kosten ab jetzt [Aufschlags-Tarif] pro 1.000 Tokens. [Plan-Vergleich auf hivegrid.de]". Web-App: direkter Link zur Vergleichs-Seite. Mobile-App: Hinweis ohne Upgrade-UI (Apple-Compliance, siehe 28.X.10).

28.X Phase 2 / bewusst NICHT in Phase 1

28.X.1 In-App-Plan-Wechsel und Add-On-Käufe (alles muss zur Marketing-Site, Apple-Compliance Phase 1). 28.X.2 Mehr-Mandanten-Abrechnung für Konzerne (mehrere Mandanten in einer Legacy-Provider-Subscription gebündelt). 28.X.3 Individual-Pricing pro Mandant durch Plattform-Admin (Enterprise-Verhandlung). 28.X.4 Promo-Code-System mit Rabatt-Codes im Bezahlvorgang. 28.X.5 Jahres-Abrechnung mit konfigurierbarem Jahres-Rabatt. 28.X.6 Self-Service-Trial ohne Vertriebs-Freigabe (mit Zahlungsmethoden-Pflicht). 28.X.7 Reseller-Modell (Agentur kauft Subscription für Endkunden-Mandanten mit eigener Marge). 28.X.8 KI-basierte Verbrauchs-Vorhersage („bei aktuellem Verbrauch wirst du den Plan in 7 Tagen sprengen"). 28.X.9 Self-Service-Kündigungs-Umfrage mit Auto-Discount-Angebot. 28.X.10 Apple-Compliance-Sonderregel: keine Pricing-Tabelle, keine Plan-Vergleichs-UI, keine Upgrade-Buttons, keine Add-On-Käufe und keine Werbe-Banner für höhere Pläne in der Mobile-App. Stattdessen Hinweis-Box: „Plan-Wechsel über deinen Account-Manager oder hivegrid.de" mit externem Link in neuem Tab.

28.Y Klartext-Fehlertexte (Beispiele)

28.Y.1 Trial freigeschaltet: „Dein HiveGrid-Trial ist freigeschaltet. Bis [Datum] kannst du alles testen." 28.Y.2 Trial endet bald: „Dein Trial endet in 3 Tagen am [Datum]. Plan wählen unter hivegrid.de" 28.Y.3 Trial abgelaufen: „Dein Trial ist abgelaufen. Workspace ist Read-Only. Plan wählen unter hivegrid.de" 28.Y.4 Erste Zahlung gescheitert: „Zahlung gescheitert für Rechnung vom [Datum]. Wir versuchen es in [N] Tagen erneut. [Zahlungsmethode aktualisieren]" 28.Y.5 Letzte Mahnstufe: „Letzter Zahlungsversuch fehlgeschlagen. Konto wird in 24h gesperrt. [Zahlungsmethode aktualisieren]" 28.Y.6 Pause aktiv: „Workspace pausiert seit [Datum]. Reaktivieren um wieder zu schreiben." 28.Y.7 Klick auf Schreib-Button im Read-Only-Modus: „Diese Aktion ist nicht möglich, weil dein Workspace pausiert ist. [Reaktivieren]" 28.Y.8 Sitzplatz-Limit erreicht: „Plan-Limit von [N] [Typ]-Sitzplätzen erreicht. Plan-Wechsel über hivegrid.de" 28.Y.9 Trigger-Limit: „Automation-Trigger-Limit erreicht für diese Periode. Eingehende Trigger werden verworfen bis [Periodenstart]." 28.Y.10 Bezahl-Session abgelaufen: „Die Bezahl-Session ist abgelaufen. Bitte Plan-Wahl wiederholen." + Direkt-Link.

Modul 29: Onboarding

Was es tut: Führt einen frisch angemeldeten Mandanten in 5 Minuten von der nackten Anmeldung in einen einsatzbereiten Workspace, mit branchen-spezifischer Standard-Konfiguration, optionalen Beispieldaten und Mitarbeiter-Einladung.

Warum es wichtig ist: Wenn der Mandant nach Anmeldung in einer leeren App landet und nicht weiß, wo er anfangen soll, ist er weg. Onboarding entscheidet über die Aktivierungs-Quote. Branchen-Templates müssen so abgelegt sein, dass Phase 2 weitere Branchen ohne Code-Patch möglich macht.

29.1 Mandanten-Anmeldung (Tenant-Anlage)

29.1.1 Anmelde-Pfad: Marketing-Site hivegrid.de/signup → in-App-Account-Anlage → Mandanten-Daten → Plan-Auswahl → Legacy-Provider-Bezahlvorgang → Onboarding-Wizard. 29.1.2 Beim ersten Login auf der Mandanten-Adresse: automatische Weiterleitung in den Wizard. 29.1.3 Wizard läuft im Vollbild-Modus ohne Sidebar, mit Fortschritts-Anzeige. 29.1.4 Wizard ist resumable, bei Abbruch wird beim nächsten Login zum letzten Schritt zurückgekehrt. 29.1.5 Pro Schritt sofortige Validierung; Pflicht-Felder sind als solche gekennzeichnet. 29.1.6 Rückwärts-Navigation möglich, außer bei irreversiblen Schritten wie der Beispieldaten-Anlage.

29.2 Schritte des Wizards

29.2.1 Willkommens-Begrüßung mit Vorschau der nächsten Schritte und geschätzter Dauer. 29.2.2 Firmendaten bestätigen, Firmenname, USt-IdNr., Adresse. 29.2.3 Branche bestätigen (siehe 29.3). 29.2.4 Größe bestätigen, Auswahl 1–10 / 11–25 / 26–50 / 51–100 / 100+ Mitarbeiter. 29.2.5 Logo (optional), Upload mit Format-Hinweis (PNG/JPG/SVG, max. 2 MB). 29.2.6 Smart-Setup-Vorschau, Klartext welche Pipelines, Rollen, Custom-Felder, Form-Templates angelegt werden, mit Toggle pro Template-Gruppe. 29.2.7 Beispieldaten, Klartext-Frage mit Default „Ja" (siehe 29.4). 29.2.8 Mitarbeiter einladen, siehe 29.5. 29.2.9 Erste-Schritte-Liste, Klartext-Erklärung der Checkliste, kein Eingabe-Schritt. 29.2.10 Fertig, Klartext-Bestätigung, Direkt-Link ins Mandanten-Dashboard, Hinweis auf KI-Walkthrough.

29.3 Branchen-Wahl (SHK pre-selected)

29.3.1 SHK ist beim Signup vorausgewählt und zeigt sich als die einzige aktive Branche im Wizard. 29.3.2 Andere Branchen (Elektro, Maler, Sanitär, Tischlerei, Dachdecker) sind als „Coming soon" sichtbar und deaktiviert. 29.3.3 Bei Auswahl einer „Coming soon"-Branche im Signup-Formular: Klartext-Hinweis „Diese Branche ist noch in Vorbereitung. Wir richten dir vorerst die SHK-Konfiguration ein, du kannst alles anpassen." 29.3.4 Anforderung: Branchen-Templates sind deklarativ in einer Verzeichnis-Struktur abgelegt, pro Branche ein Ordner mit YAML-Dateien für Pipelines, Rollen, Form-Templates, Custom-Felder, Beispieldaten, Erste-Schritte-Checkliste. Eine neue Branche aufzunehmen heißt: einen neuen Ordner mit Templates anlegen, kein Code-Patch nötig. 29.3.5 Templates werden beim System-Start eingelesen; beim Anlegen eines Mandanten mit gewählter Branche wird das passende Template angewandt. 29.3.6 Alle geseedeten Inhalte sind nach Setup vom Mandanten-Admin frei änderbar, kein „Locked Template".

29.4 Demo-Daten-Provisioning

29.4.1 Beispieldaten geben dem User sofort etwas zum Anschauen, keine leere App. 29.4.2 SHK-Default: ca. 10 Beispiel-Kontakte (Privat/B2B-Mix), 3 Beispiel-Firmen, 5 Beispiel-Deals in unterschiedlichen Stages, 1 aktives Beispiel-Projekt mit Chat-Verlauf, Aufgaben und Foto-Checkliste, 1 Beispiel-Lead in der Inbox, ca. 5 Beispiel-Dateien (PDFs, JPGs), Beispiel-Tags und eine Beispiel-Booking-Page. 29.4.3 Alle Beispieldaten sind als „Demo" markiert. In allen Listen-Ansichten gibt es einen Filter „Demo-Daten ausblenden". 29.4.4 Nach 30 Tagen werden die Demo-Daten NICHT automatisch gelöscht, sie bleiben als reguläre Daten und können vom User manuell entfernt werden. 29.4.5 Im Mandanten-Admin gibt es eine Bulk-Lösch-Funktion „Alle Demo-Daten löschen" mit Multi-Step-Bestätigung. 29.4.6 Klartext im Wizard: „Wir legen Beispiel-Kontakte und ein Beispiel-Projekt an, damit du sofort siehst wie HiveGrid funktioniert. Du kannst sie jederzeit löschen."

29.5 Rolle Admin → erste Nutzer einladen

29.5.1 Wizard-Schritt 8 nutzt das normale Mitarbeiter-Einladungs-System: E-Mail + Rolle pro Zeile, beliebig viele Zeilen, optional persönliche Nachricht. 29.5.2 Eingeladene Mitarbeiter erhalten eine E-Mail mit Magic-Link und können sofort starten. 29.5.3 Rollen-Vorauswahl: erste Zeile Default „Vertriebler" (häufigster Fall), per Dropdown änderbar. 29.5.4 E-Mail-Format wird live geprüft, Duplikate innerhalb des Formulars werden abgefangen. 29.5.5 „Später einladen"-Skip-Button überspringt den Schritt komplett. 29.5.6 Klartext: „Eingeladene Mitarbeiter erhalten eine E-Mail mit Magic-Link. Sie können sofort anfangen, du musst nicht warten." und „Die Rolle bestimmt, was deine Mitarbeiter in HiveGrid dürfen. Du kannst sie jederzeit ändern." 29.5.7 Bulk-CSV-Import von Mitarbeitern ist Phase 2.

29.6 Erste-Schritte-Checkliste

29.6.1 Nach Wizard-Abschluss erscheint im Mandanten-Dashboard eine Status-getrackte Checkliste. 29.6.2 Default-Items für SHK Phase 1: KWP-Verbindung einrichten, E-Mail-Postfach verbinden, AirCall verbinden, Booking-Page anlegen, Mitarbeiter einladen, erste Automation testen, erstes Form anlegen, erste Sales-Pipeline-Bewegung. 29.6.3 Pro Item: Klartext-Titel, Beschreibung, Direkt-Link in den Modul-Bereich. 29.6.4 Status wird automatisch erkannt aus dem Tenant-Stand (z.B. mindestens eine aktive Automation = erledigt). 29.6.5 Mitarbeiter können Items manuell als „erledigt" markieren oder die Liste dauerhaft ausblenden. 29.6.6 Nach 100% Erledigung automatisches Ausblenden mit Glückwunsch-Klartext: „Alle Erste-Schritte erledigt, viel Erfolg mit HiveGrid!"

29.7 KI-Walkthrough

29.7.1 Nach Wizard-Abschluss optional ein KI-geführter Rundgang. 29.7.2 Auf User-Klick: KI fragt „Was willst du heute zuerst machen, einen Lead bearbeiten, ein Projekt erstellen oder Mitarbeiter einrichten?" und navigiert in den entsprechenden Modul-Bereich mit Kontext-Hinweisen. 29.7.3 KI hat Zugriff auf Mandanten-Stand, Erste-Schritte-Checkliste und Hilfe-Center-Artikel, keine schreibenden Aktionen ohne explizite User-Bestätigung. 29.7.4 Permanent abschaltbar in den User-Einstellungen.

29.X Phase 2 / bewusst NICHT in Phase 1

29.X.1 Branchen-Templates für Elektro, Maler, Sanitär, Tischlerei, Dachdecker (deklarativ, gleiche Verzeichnis-Struktur). 29.X.2 Migrations-Tools für HubSpot, Quiply und KWP-Bestandsdaten. 29.X.3 CSV-Bulk-Import für Bestandsdaten als optionaler Wizard-Schritt. 29.X.4 KI-gestützter Onboarding-Coach, der aus dem Mandanten-Verhalten lernt. 29.X.5 Re-Onboarding für bestehende Mandanten bei neuen Templates. 29.X.6 Multi-Branchen-Mandant (SHK plus Elektro gleichzeitig). 29.X.7 Onboarding-Analytics für Plattform-Admin (Skip-Quote, Abbruch-Punkte, durchschnittliche Dauer). 29.X.8 Custom-Onboarding pro Mandant für die internen Mitarbeiter-Schulungen.

29.Y Klartext-Fehlertexte (Beispiele)

29.Y.1 Welcome: „Willkommen bei HiveGrid! Wir helfen dir, dein Workspace in 5 Minuten einsatzbereit zu machen." 29.Y.2 Smart-Setup-Fehler: „Wir konnten die Pipeline nicht anlegen. Wir versuchen es nochmal, falls es wieder fehlschlägt, kontaktiere bitte den Support." + Retry-Button. 29.Y.3 Logo zu groß: „Das Logo ist zu groß (max. 2 MB). Bitte kleineres Bild wählen." 29.Y.4 Logo-Format ungültig: „Logo muss PNG, JPG oder SVG sein." 29.Y.5 Ungültige Mitarbeiter-E-Mail: Inline-Hinweis pro Zeile „Diese Email ist nicht gültig." 29.Y.6 Mitarbeiter ist bereits Mitglied: „[Email] ist bereits Mitglied, Rolle: [Rolle]" 29.Y.7 Branchen-Template nicht ladbar (Edge-Case): „Konnte SHK-Template nicht laden. Plattform-Admin wurde benachrichtigt." + Auto-Alert.

Modul 34: Public API & Webhooks

Was es tut: Stellt Drittanbietern eine begrenzte Schnittstelle zur Verfügung, um HiveGrid-Daten zu lesen und um Webhooks zu empfangen, wenn etwas im Mandanten passiert. Außerdem ein Eingangs-Tor für Lead-Push aus externen Form-Anbietern.

Warum es wichtig ist: Webseiten, externe Form-Anbieter und ERPs müssen Leads in HiveGrid einkippen können. Andere Tools wollen sich abonnieren, wenn z.B. ein Deal gewonnen wurde. Wir bauen Phase 1 bewusst klein, Lese-Zugriff plus Webhooks reichen erstmal.

34.1 Read-API für Drittanbieter

34.1.1 Zugriff per API-Schlüssel (Verwaltung im Mandanten-Admin); Header Authorization: Bearer hg_<Schlüssel>. 34.1.2 Bereitgestellte Lese-Endpunkte für: Kontakte, Firmen, Deals, Projekte, Aufgaben, Leads, jeweils Liste und Detail. 34.1.3 Standard-Funktionen: Cursor-Pagination (Default 50, max. 200 pro Seite), Filterung per Query-Parameter (auch Datums-Bereiche und Custom-Felder), Sortierung, sparse fieldsets (nur bestimmte Felder zurückgeben), eingebettete Beziehungen (z.B. Deal mit Pipeline und Stage als Sub-Objekte; Tiefe maximal 1 in Phase 1). 34.1.4 Berechtigungs-Modell („Scopes"): „Read-Only" gibt Zugriff auf nicht-sensible Felder; „Read-Full" inkl. Notizen, sensiblen Custom-Feldern, Activities; „Webhook-Inbound" nur für Eingangs-Webhooks; „Automation-Trigger" für externe Event-Pushes an die Automation-Engine. 34.1.5 Phase 1: ein Schlüssel = ein Scope. Mehrfach-Scope-Schlüssel und granulare Modul-Scopes erst Phase 2. 34.1.6 Sensible Felder werden bei „Read-Only" automatisch aus Antwort entfernt, nicht 403, sondern Feld wird einfach weggelassen (im OpenAPI-Schema dokumentiert). 34.1.7 Antwort-Format einheitlich: { data, meta } bei Erfolg, { error: { code, message, details } } bei Fehler, Klartext-Fehlertexte in Deutsch. 34.1.8 OpenAPI-Spezifikation auto-generiert (/api/v1/openapi.json), Swagger-UI öffentlich verfügbar mit „Try it out"-Funktion. 34.1.9 Versionierung über URL (/api/v1/...); Major-Bump nur bei Breaking Changes; Deprecation-Phase und Sunset-Header bei Alt-Endpunkten. 34.1.10 Statt Tenant fünf-vor-zwölf-Frozen wird auf API-Schreiboperationen mit 402 (Bezahl-Pflicht) geantwortet, Lesen bleibt erlaubt.

34.2 Webhooks (signiert)

34.2.1 Eingehende Webhooks (Lead-Push aus Web-Formularen): - Pro Mandant beliebig viele „Slugs" konfigurierbar (z.B. website-kontaktformular). - Authentifizierung wahlweise: API-Schlüssel im Header, HMAC-Signatur über Body, oder Token in der URL (mit Klartext-Warnung, dass das weniger sicher ist). - Eingangs-Webhook erzeugt einen Lead (oder direkt Kontakt, je nach Slug-Konfiguration), wendet Default-Tags und Default-Zuordnung an, prüft auf Duplikate (gleiche E-Mail). - Verarbeitungs-Logs sichtbar im Mandanten-Admin: letzte 100 Eingangs-Events mit Status, Fehler-Klartext und Replay-Button (Replay Phase 2). 34.2.2 Ausgehende Webhooks (Subscription-Modell): - Mandant abonniert beliebige Event-Typen wie contact.created, deal.stage_changed, project.completed, lead.qualified. - Pro Subscription: eindeutige Ziel-URL, system-generiertes HMAC-Geheimnis (einmalig sichtbar bei Anlage), optionaler Filter pro Event. - Auslieferung mit HMAC-SHA256-Signatur im Header X-HiveGrid-Signature, Event-ID-Header für Idempotenz beim Empfänger. - Retry mit exponentiellem Backoff (1min, 5min, 30min, 2h, 12h), max. 5 Versuche bei 5xx/Timeout. 4xx wird nicht wiederholt. - Nach 10 aufeinanderfolgenden Fehl-Auslieferungen wird die Subscription automatisch deaktiviert mit Klartext-Hinweis. - Test-Funktion „Test-Event senden" im Subscription-Detail. - Statistik-Sicht: letzte 100 Auslieferungen, Aggregat „letzte 7 Tage X von Y erfolgreich". 34.2.3 Allgemeine Event-Ingestion (POST /api/v1/integrations/events) für externe Systeme, die Custom-Events in die Automation-Engine pushen wollen, Phase 1 nur als Trigger, keine direkte Datenmanipulation.

34.3 Rate-Limiting und Logs

34.3.1 Standard-Limit pro API-Schlüssel: 1.000 Anfragen/Stunde, kurzfristig 50/Sekunde tolerabel. 34.3.2 Pro Mandant aggregiert: 10.000 Anfragen/Stunde. 34.3.3 Eingangs-Webhooks pro Slug: 100/Minute. 34.3.4 Mandanten-Admin kann Limit pro Schlüssel auf max. 10.000/h erhöhen ohne Plattform-Admin-Approval. 34.3.5 Antwort-Header X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset bei jeder Antwort. Bei Überschreitung 429 mit Klartext und Retry-After-Header. 34.3.6 API-Request-Logs im Mandanten-Admin sichtbar: 90 Tage erfolgreiche, 180 Tage Fehler-Requests.

34.4 Anti-Liste: kein Schreib-API in Phase 1

34.4.1 Kein POST/PUT/PATCH/DELETE auf Hauptentitäten in Phase 1, nur Lese-Endpunkte und Webhooks. 34.4.2 Kein GraphQL. 34.4.3 Kein OAuth2-Provider-Modus für Drittanbieter-Apps (3-Legged-OAuth). 34.4.4 Keine granularen Modul-spezifischen Scopes. 34.4.5 Keine Bulk-Export-Endpunkte über die API (Vollexport läuft über Modul 35 DSGVO-Export). 34.4.6 Kein API-Schlüssel-Rotation-Workflow mit Übergangs-Fenster. 34.4.7 Keine Plattform-Admin-API.

34.X Phase 2 / spätere Features

34.X.1 Voll-CRUD-API für alle Hauptentitäten. 34.X.2 GraphQL-Endpunkt als zweite Schnittstelle. 34.X.3 OAuth2-Provider-Modus für Drittanbieter-Apps. 34.X.4 Granulare Scopes pro Modul-Aktion. 34.X.5 Webhook-Replay-Tool im UI. 34.X.6 Bulk-Export-Endpunkt über die API. 34.X.7 Komplexe Filter über JSON-Query-Tree. 34.X.8 Rate-Limit-Tier-Erhöhung über Plan (Cloud+ = 5.000/h). 34.X.9 API-Schlüssel-Rotations-Workflow.

34.Y Klartext-Fehlertexte (Beispiele)

34.Y.1 Header fehlt (401): „API-Key fehlt. Setze Header: Authorization: Bearer hg_<dein_key>" 34.Y.2 Schlüssel ungültig (401): „API-Key ist ungültig oder widerrufen." 34.Y.3 Falscher Scope (403): „Dieser API-Key hat Scope [X], benötigt wird [Y]. Tenant-Admin kann Scope ändern." 34.Y.4 Eingehender Webhook ungültiges Payload: „Pflichtfeld email fehlt im Payload. Erwartetes Schema: [Link zur Mapping-Doku]" 34.Y.5 Webhook deaktiviert: „Webhook ‚[Name]' ist nach 10 fehlgeschlagenen Auslieferungen deaktiviert. Letzter Fehler: HTTP 502 vom Endpoint. [Reaktivieren]" 34.Y.6 Rate-Limit: „Rate-Limit erreicht: 1.000 Anfragen/Stunde. Reset um [timestamp]. Tenant-Admin kann Limit erhöhen." 34.Y.7 Validierung: „Filter created_at_gte muss ISO-8601 sein, z.B. 2026-01-01. Erhalten: [Wert]."

Modul 35: DSGVO-Export / Account-Löschung

Was es tut: Erfüllt zwei rechtliche Pflichten gleichzeitig: das DSGVO-Auskunfts- und Datenportabilitäts-Recht (Daten-Export) und die Apple-Pflicht aus 2022, dass jede iOS-App eine Account-Löschung anbieten muss. Außerdem den Mandanten-Lösch-Workflow nach Kündigung, AVV-Vertrag im Onboarding und die Subprozessoren-Liste.

Warum es wichtig ist: Pflicht durch Apple und durch DSGVO. Ohne dieses Modul kann die App nicht in den App-Store, und Behörden-Auskünfte sind nicht erfüllbar. Außerdem: glaubwürdige Datenportabilität ist Marketing-Argument gegen den Vendor-Lock-in vieler CRMs.

35.1 Export aller Daten eines Kontakts/Mitarbeiters

35.1.1 Jeder Mitarbeiter darf jederzeit alle Daten, die mit seiner Person verknüpft sind, in maschinenlesbarem Format anfordern (DSGVO Art. 15 + Art. 20). 35.1.2 Inhalt des User-Daten-Exports: - Stammdaten: E-Mail, Name, Sprache, 2FA-Status, OAuth-Verknüpfungen, Benachrichtigungs-Einstellungen, aktive Sitzungen (gekürzt: nur Geräte-Liste, keine Tokens). - Mandanten-Mitgliedschaft: Rollen, Gruppen, Beitritts-Datum, Rechte-Snapshot. - Eigene Inhalte: Aktivitäten, Notizen, Chat-Nachrichten, Aufgaben, Termine, hochgeladene Dateien (Metadaten + Originale), Form-Submissions, eigene HR-Daten (eigene Krankmeldungen, Urlaubsanträge, Lohnzettel, NICHT die der Kollegen). - Kommunikation: gesendete und empfangene E-Mails inkl. Anhänge. - Eigene KI-Konversations-Historie und Audit-Spuren als Akteur. 35.1.3 Format: ZIP-Archiv mit klar strukturierten Unterordnern (Profil, Mitgliedschaften, Aktivitäten, Chat, Notizen, Aufgaben, Termine, Dateien, E-Mails, HR, KI-Konversationen, Audit). README im ZIP erklärt Klartext, was drin ist. 35.1.4 Export-Job läuft asynchron, bei großem Datenbestand in Häppchen mit Progress-Update. 35.1.5 Download-Link gültig 7 Tage; danach automatische Löschung der ZIP-Datei. Magic-Link gegen Auth-Bypass. 35.1.6 Maximal 3 aktive User-Daten-Export-Jobs pro Person pro 24 Stunden (Schutz vor Missbrauch).

35.1.7 Mandanten-Admin-Daten-Export (komplettes Mandanten-Volumen): - Inhalt: alle Mandanten-Daten als JSON-Files plus alle Original-Dateien (CRM, Pipelines, Projekte, Aufgaben, Forms, Bookings, E-Mails, Chats, Telefonate, HR-Hub, Customer-Portal, Automationen, KI-Konversationen, KWP-Sync-Daten, Audit-Trail, Mitarbeiter-Liste, Rollen, Tags). - Anwendungsfall: DSGVO-Auskunft für die Firma als Verantwortlicher und Vendor-Lock-in-Vermeidung beim Wechsel weg von HiveGrid. - ZIP kann mehrere Gigabyte groß sein, bei sehr großen Mandanten Multi-Part-ZIP. - Vor Submit: Klartext-Hinweis mit geschätzter Größe und Dauer. - Maximal 1 aktiver Mandanten-Export pro Mandant. - Mandant in „pausiert" oder „Zahlung überfällig": Export bleibt erlaubt, Lese-Recht hat Vorrang. - Mandant in 30-Tage-Lösch-Vorlauf: Export erlaubt mit Klartext-Hinweis „Letzte Möglichkeit, Daten zu sichern bevor Tenant gelöscht wird."

35.2 Account-Löschung (Apple-Pflicht)

35.2.1 Apple-Pflicht seit 2022, jede iOS-App MUSS eine Account-Löschung in der App selbst anbieten. Pflicht durch Apple und durch DSGVO. 35.2.2 Sichtbarer Pfad: in den Konto-Einstellungen auf gleicher Ebene wie das Profil (Reviewer prüft Sichtbarkeit aktiv). 35.2.3 Multi-Step-Bestätigung gegen Versehen: - Schritt 1: Klartext-Erklärung was passiert (Daten weg, Mandanten-Mitgliedschaften beendet, Login-Möglichkeit weg). - Schritt 1.5: Angebot, vorher die eigenen Daten zu exportieren (siehe 35.1). - Schritt 2: Identitäts-Bestätigung (Passwort + 2FA falls aktiv). - Schritt 3: Final-Klick mit Tipp-Eingabe einer Confirm-Phrase. 35.2.4 Was technisch passiert: Mandanten-Mitgliedschaften werden gelöscht, persönliche Daten mit Platzhalter überschrieben, Audit-Spuren behalten die User-ID (für Nachvollziehbarkeit), 2FA-Geheimnisse, aktive Sitzungen, Push-Tokens, OAuth-Konten und Avatar werden entfernt. 35.2.5 24-Stunden-Reverse-Window: nach Klick erhält der User eine Bestätigungs-E-Mail an die Lösch-Adresse, kann innerhalb 24h zurückziehen. Erst danach unwiderruflich. 35.2.6 In der Mobile-App werden zusätzlich alle lokalen Daten gelöscht (lokaler Cache, Biometrie-Token, Push-Token revoke).

35.3 Aufbewahrungsfrist nach Löschung (Mandanten-Lösch-Workflow)

35.3.1 Mandanten-Kündigung läuft als Multi-Step-Workflow: - Schritt 1: Klartext-Erklärung was passiert (Status wechselt sofort auf „Lösch-Vorlauf", Workspace bleibt 30 Tage Read-Only sichtbar, danach Hard-Delete aller Daten unwiderruflich). - Schritt 2: Datensicherungs-Hinweis mit Direkt-Link zum Mandanten-Export. - Schritt 3: Legacy-Provider-Hinweis (Restbetrag, Pro-rata-Erstattung, letzte Rechnung). - Schritt 4: Identitäts-Bestätigung (Passwort + 2FA). - Schritt 5: Final-Klick mit Eingabe des Mandanten-Slugs als Confirm-Phrase. 35.3.2 30-Tage-Grace-Period: jeder Mandanten-Admin kann mit einem Klick zurückziehen, Status zurück auf „aktiv". Audit dokumentiert wer kündigte und wer zurückzog. 35.3.3 Banner im Workspace während Grace-Period: „Konto wird in X Tagen gelöscht, [Kündigung zurückziehen]" 35.3.4 Hard-Delete-Cron läuft täglich nach Ablauf der Grace-Period: - Reihenfolge: Dateien im Storage rekursiv löschen → Embeddings → Worker-Queues für diesen Mandanten verwerfen → Webhook-Subscriptions deaktivieren → DB-Daten in FK-konformer Reihenfolge → Cache-Keys purgen. - Nach Hard-Delete bleibt nur Metadaten im Plattform-Audit-Log (Lösch-Datum, Akteur, Grund), keine PII, keine User-Inhalte mehr. - Bestätigungs-E-Mail an den AVV-Unterzeichner: „Tenant ‚X' wurde am [Datum] vollständig gelöscht. DSGVO-Auftrag erfüllt." 35.3.5 Andere Lösch-Gründe außer freiwillig: - Nichtzahlung, automatisch nach 30 Tagen „Zahlung überfällig" (siehe Modul 28.4). - AGB-Verstoß, Plattform-Admin kündigt manuell, ggf. verkürzte Grace-Period. - Admin-initiiert auf Anfrage des Mandanten-Admin per E-Mail mit Bestätigungs-Link.

35.4 AVV-Vertrag und Subprozessoren-Liste

35.4.1 Beim Signup ist die AVV-Akzeptanz Pflicht-Checkbox. Beim Klick: dynamisch generiertes PDF mit Mandanten-spezifischen Daten (Firma, Anschrift, GF-Name, Datum, aktuelle Subprozessoren-Liste, Versionsnummer). 35.4.2 Bei jedem AVV-Update wird Re-Akzeptanz beim nächsten Login verlangt (Modal mit Klartext-Änderungen). Nach 14 Tagen ohne Re-Akzeptanz: Read-Only-Modus. 35.4.3 Mandanten-Admin sieht in den Datenschutz-Einstellungen alle akzeptierten AVV-Versionen mit Datum und Unterzeichner; PDF-Download jederzeit möglich. 35.4.4 Subprozessoren-Liste: - Sichtbar im Datenschutz-Bereich des Mandanten-Admins. - Pro Eintrag: Name, Land, EU/EEA-Indikator, Zweck-Klartext, Datenkategorien, Link zum AVV-Template, „Aktiv seit"-Datum. - Bei neuem Subprozessor: E-Mail an alle Mandanten-Admins, 14-Tage-Widerspruchs-Frist (gesetzliche AVV-Pflicht). - Phase 1 EU-Stack: Liste enthält ausschließlich EU/EEA-Anbieter (Scaleway etc.), keine Drittland-Transfers. 35.4.5 Privacy-Manifest für die Mobile-App (Apple-Pflicht seit 2024) wird aus einer zentralen Master-Liste beim Build generiert; öffentliche Privacy-Manifest-Seite verfügbar.

35.5 Berechtigungen

35.5.1 Eigener User-Daten-Export: jeder eingeloggte Mitarbeiter implizit. 35.5.2 Mandanten-Daten-Export: Mandanten-Admin oder spezielles Recht. 35.5.3 Mandanten-Lösch-Workflow: Mandanten-Admin. 35.5.4 Subprozessoren-Liste lesen: jeder Mandanten-Admin. 35.5.5 AVV (re-)akzeptieren: jeder Mandanten-Admin. 35.5.6 Phase 1: Mandanten-Admin kann NICHT für andere Mitarbeiter Daten exportieren, jeder nur für sich. Vertretungsfall ist Phase 2.

35.X Phase 2 / spätere Features

35.X.1 Pseudonymisierungs-Toggle pro Modul (z.B. E-Mail-Adressen im Export gehasht). 35.X.2 Drittland-Audit-Log mit Begründung pro Datentransfer. 35.X.3 DSFA-Generator (Datenschutz-Folgeabschätzung) als automatisch generiertes PDF pro Mandant. 35.X.4 Scope-gefilterter Export (nur CRM, nur HR, etc.) statt immer Vollexport. 35.X.5 Inkrementelle Exports „nur seit letztem Export". 35.X.6 Auto-Delete-Schedules pro Entity-Typ (z.B. „Lost-Leads automatisch nach 90 Tagen löschen"). 35.X.7 User-Daten-Export für andere Mitarbeiter durch Mandanten-Admin (Vertretungsfall). 35.X.8 Verschlüsselter Export mit User-Passwort (AES). 35.X.9 Export-API für regelmäßige automatische Backups durch den Mandanten. 35.X.10 Konsolidierte Privacy-Center-Page mit allen DSGVO-Aspekten in einer Übersicht.

35.Y Klartext-Fehlertexte (Beispiele)

35.Y.1 Export dauert lange: „Dein Export dauert länger als erwartet. Wir versuchen es weiter, du bekommst eine Email sobald fertig." 35.Y.2 Export abgelaufen: „Dieser Export ist abgelaufen und wurde gelöscht. [Neuen Export starten]" 35.Y.3 Concurrent-Limit: „Du hast bereits 3 aktive Export-Anforderungen in den letzten 24 Stunden. Bitte warte bis einer fertig ist." 35.Y.4 Trial-Kündigung: „Dein Tenant ist im Trial, Kündigung beendet sofort den Zugang ohne Grace-Period. [Trotzdem fortfahren]" 35.Y.5 AVV-Re-Akzeptanz blockiert: „Bitte unsere aktualisierte AVV akzeptieren, um den Workspace weiter zu nutzen." 35.Y.6 Subprozessor-Widerspruch verstrichen: „Du hast nicht widersprochen. Der neue Subprozessor wird ab [Datum] wirksam."

Modul 36: Mobile-App (Capacitor)

Was es tut: Eine native iOS- und Android-App, die in Wirklichkeit die mobile-first Web-App in einen App-Store-tauglichen Container verpackt, App auf Web-Basis, ins iOS-/Android-Format verpackt. Drei Pflicht-Native-Features (Push-Benachrichtigungen, Face-ID/Touch-ID-Anmeldung, Kamera) plus ein vollwertiger Offline-Modus für die Baustelle.

Warum es wichtig ist: Monteure draußen ohne Empfang müssen weiterarbeiten können, Acceptance-Protokolle, Foto-Checklisten, Aufgaben-Statusen. Apple stellt strikte Compliance-Anforderungen, die ohne Mobile-App-Strategie zu Reject-Risiko führen. Account-Löschung in der App ist Apple-Pflicht.

36.1 Capacitor-Wrapper iOS+Android

36.1.1 Eine einzige Code-Basis: die mobile-first responsive Web-App ist die Quelle der Wahrheit. Capacitor packt diese Web-App in ein natives Hülle für iOS und Android. 36.1.2 Native Plugins werden über eine zentrale Schnittstelle aufgerufen, im Browser geben sie nichts zurück, im Capacitor-Container den echten nativen Aufruf. 36.1.3 CI/CD: Tag mobile-vX.Y.Z triggert separate Pipelines für Web-Build, iOS-Build (TestFlight-Upload) und Android-Build (Google-Play-Upload). 36.1.4 Versionierung getrennt: Wrapper-Version (im App-Store sichtbar, semantic versioning) und Web-Bundle-Version. Eine vom Server gepflegte Mindest-Wrapper-Version erzwingt bei zu alten Apps einen Force-Update-Screen. 36.1.5 Lokale Dev-Umgebung mit Capacitor-CLI Live-Reload, Push-Test-Tools, Biometrie-Simulation.

36.2 Native Features (Pflicht für Apple-Compliance)

36.2.1 Push-Benachrichtigungen: - Bei erstem Login auf Gerät: Pre-Prompt-Erklärung „HiveGrid sendet dir Benachrichtigungen, wenn dir eine Aufgabe zugewiesen wird oder wichtige Updates passieren, möchtest du das aktivieren?" mit Funktionen „Ja, aktivieren" und „Später" VOR dem System-Dialog. - Bei Zustimmung: Push-Token holen und im Mandanten registrieren. - App im Vordergrund: visualisiert in der App. App im Hintergrund: System-Notification-Center. - Klick auf Push öffnet die App auf der entsprechenden Tiefenroute. 36.2.2 Face-ID / Touch-ID-Anmeldung: - Setup in den Sicherheits-Einstellungen: Toggle aktivieren → Passwort eingeben → wird im sicheren Apple-/Android-Speicher hinterlegt. - Beim nächsten Login: „Mit Face-ID anmelden"-Funktion. Bei 3 Fehl-Versuchen: Fallback auf Passwort. - 2FA bleibt trotzdem aktiv, Biometrie ersetzt nur das Passwort, nicht den 2. Faktor. - Auth-Geheimnis bleibt nur lokal im OS-Keychain, nicht auf dem Server. 36.2.3 Kamera: - Pre-Prompt-Erklärung „HiveGrid braucht Zugriff auf deine Kamera, um Fotos für Acceptance-Protokolle und Checklisten aufzunehmen, möchtest du das erlauben?" - Foto-Capture-Optionen: direkt aufnehmen oder aus Galerie auswählen. - Lokales Foto-Resize (max. 2400×2400, JPEG-Qualität 85) vor Upload zur Bandbreiten-Schonung. - Online: direkter Upload. Offline: Foto in lokalem Speicher mit Upload-Auftrag (siehe 36.3). 36.2.4 Phase 1 keine: Geolocation, Bluetooth, NFC, Mikrofon, alle Phase 2.

36.3 Offline-Modus (Phase-1-Pflicht für Baustelle)

36.3.1 Architektur: Offline-Speicher auf dem Gerät plus Synchronisation bei Wiederverbindung. Service-Worker für statische App-Inhalte, lokaler Datenspeicher für eigene Daten und für Fotos. 36.3.2 Beim Login wird automatisch vorgeladen: - Heutige zugewiesene Projekte des Users. - Heute fällige und offene Aufgaben. - Stammdaten (Kontakte verknüpft mit aktiven Projekten, eigenes Profil, Berechtigungen). - Acceptance-Protokoll-Templates und Foto-Checklisten für aktive Projekte. - Klartext beim Pre-Cache: „Lade Daten für offline-Nutzung, bitte einen Moment Geduld..." mit Fortschritts-Anzeige. 36.3.3 Was funktioniert offline: - Anzeige der vorgeladenen Daten und Navigation in allen vorgeladenen Bereichen. - Anzeige eigener offline-erzeugter Einträge. 36.3.4 Was NICHT offline funktioniert: - Suche über nicht-gecachte Daten (z.B. CRM-Vollsuche). - Server-side gerenderte Reports und KI-Antworten. - E-Mail-Inbox (Phase 2 erweitert). - Chat-Echtzeit-Updates (Lesen vorhandener Threads ja; Senden geht in die Warteschlange). 36.3.5 Was kann offline geschrieben werden (landet in einer lokalen Warteschlange und wird später synchronisiert): - Fotos hochladen zu Acceptance, Projekt-Dateien, Aufgaben. - Notizen, Aufgaben-Status (Offen → In Bearbeitung → Erledigt), Checklist-Items abhaken, Acceptance-Protokoll erstellen und abschließen, manuelle Activity-Einträge, Termin-Status setzen, Datei-Anhänge, Chat-Nachricht in Projekt-Channel. 36.3.6 Bewusst NICHT offline: - Anlegen neuer Kontakte/Firmen (zu hohes Konflikt-Risiko bei CRM-Stammdaten). - Lead-Bearbeitung (Vertriebs-Use-Case ist online-zentriert). - Berechtigungs- und User-Aktionen (sicherheitsrelevant). 36.3.7 Sichtbarer Sync-Status: Anzahl wartender Änderungen, Klick öffnet Warteschlange-Übersicht mit Status pro Eintrag und manuellem Retry. 36.3.8 Synchronisation bei Wiederverbindung: - Wird ausgelöst durch Netzwerk-Status-Wechsel, App-Vordergrund-Resume, manuellen Sync, periodisch alle 60s wenn online und Warteschlange nicht leer, beim Login. - Reihenfolge: Lese-Cache aktualisieren → Schreib-Warteschlange in Eingangs-Reihenfolge abarbeiten → Lese-Cache erneut aktualisieren. - Pro Eintrag mit Idempotenz-Schlüssel, Doppel-Sync wird sauber abgefangen. 36.3.9 Konflikt-Strategien: - Append-Daten (Fotos, Notizen, neue Activities, neue Chat-Messages, Acceptance-Erstellung): keine Konflikte möglich. - Status-/Felder-Updates (Aufgaben-Status, Checklist-Items, Acceptance-Abschluss): Letzter-Schreibt-Gewinnt mit User-Sichtbarkeit. Bei Konflikt erscheint Klartext-Hinweis: „Es gab einen Konflikt, deine Änderung wurde übernommen, der vorherige Stand war: [Klartext]. [OK] [Vorherigen Stand wiederherstellen]" - Audit dokumentiert beide Stände. 36.3.10 Storage-Limits: lokale Warteschlange max. 1.000 Einträge, lokaler Foto-Speicher max. 500 MB. Bei Überschreitung Klartext-Hinweis und Block weiterer Aktionen bis Sync.

36.4 Apple-Compliance ohne Pricing-UI

36.4.1 Strikte Verbote in der App: keine Pricing-Page, keine Upgrade-Buttons, keine Links auf hivegrid.de/pricing oder Billing-Seiten, keine Werbe-Banner für höhere Pläne. 36.4.2 Statt-dessen bei Feature-Gate-Block: Klartext „Diese Funktion ist im Cloud+-Plan verfügbar. Bitte deinen Workspace-Admin kontaktieren oder hivegrid.de besuchen.", ohne Klick-Link. 36.4.3 Subscription-Status anzeigen ist erlaubt (Read-Only-Information): Status-Badge, Trial-Verbleibend-Text, ohne CTA-Button. 36.4.4 Technisch: in der Mobile-App ist ein Bau-Flag aktiv, der die gesamte Pricing-/Upgrade-UI ausblendet. 36.4.5 Sign-in-with-Apple-Umgehung: Login als „Enterprise SSO" positioniert. Phase 1 nur E-Mail/Passwort + Magic-Link (umgeht SIWA-Trigger automatisch). App-Store-Listing als „Business, Enterprise-CRM für Handwerk" mit Klartext-Reviewer-Notes „This is an enterprise B2B CRM application. Authentication is exclusively via the customer organization's account, per Guideline 4.8 enterprise/business apps exception." 36.4.6 Falls Reviewer doch SIWA fordert: Backup-Implementation in ~1 Tag aktivierbar. 36.4.7 Reviewer-Demo-Account: dedizierter Mandant apple-review mit Beispiel-Daten (5–10 Kontakte, 2–3 Projekte, Beispiel-Acceptance), Login-Credentials in App-Review-Notes. 36.4.8 Privacy-Manifest (Apple-Pflicht seit 2024) wird beim Build aus Master-Liste generiert. Datentypen, Tracking-Domains (keine in Phase 1, EU-Stack), Required-Reason-APIs deklariert. 36.4.9 Native-Tab-Bar im Capacitor-Wrapper für Top-Level-Navigation (Apple-Guideline 4.2 verlangt native Navigations-Elemente). Konfiguration je nach UI-Modus: - Baustelle-Modus (Default Mobile): Heutige Aufträge / Projekte / Aufgaben / Chat / Mehr. - Büro-Modus: Dashboard / CRM / Pipeline / Inbox / Mehr.

36.5 Account-Löschung in App (Pflicht)

36.5.1 Apple-Pflicht seit 2022, die App MUSS eine Account-Löschung in der App selbst anbieten. Vollständige Spec siehe Modul 35.2. 36.5.2 Sichtbarer Pfad in den Konto-Einstellungen auf gleicher Ebene wie Profil, Reviewer prüft das aktiv. 36.5.3 Multi-Step-Bestätigung funktioniert in der Mobile-App vollständig (kein Web-Browser-Workaround). 36.5.4 Bei Löschung in der Mobile-App werden zusätzlich alle lokalen Daten gelöscht (lokaler Cache, Biometrie-Token, Push-Token revoke), App startet danach mit leerem Login-Screen. 36.5.5 Vor-Lösch-Optional: User-Daten-Export anbieten, auf Mobile mit Klartext „Export wird per Email an dich gesendet, Download bitte am Computer." (ZIP kann groß sein).

36.6 Tiefenrouten (Universal Links)

36.6.1 Die Domain app.hivegrid.de ist als Universal Link (iOS) und App Link (Android) registriert. 36.6.2 Klick auf eine Push-Benachrichtigung mit Tiefenroute öffnet die App direkt auf dem Ziel-Bildschirm, nicht den Browser. 36.6.3 Bei nicht eingeloggtem User: Tiefenroute wird geparkt, Login zuerst, danach automatische Navigation. 36.6.4 Bei Tiefenroute zu falschem Mandanten: Mandanten-Switch-Prompt. 36.6.5 Bei fehlender Berechtigung: Klartext-Hinweis und Fallback aufs Mandanten-Dashboard.

36.7 Update-Mechanik

36.7.1 Web-Bundle-Updates: App prüft beim Start die Server-Version. Bei neuer Version: Download im Hintergrund, Klartext-Hinweis „Update verfügbar, beim nächsten App-Start aktiviert", Atomic-Swap beim nächsten Cold-Start. 36.7.2 Wrapper-Updates: regulär über App-Stores. Frequenz 1–2 Releases pro Quartal Default. 36.7.3 Force-Update bei zu alter Wrapper-Version, Sicherheits-Update oder OS-Mindestversion-Erhöhung, Modal ohne Schließen-Funktion mit Klartext-Grund und App-Store-Link.

36.8 Submission-Strategie

36.8.1 Reihenfolge: Google Play zuerst (niedrigere Hürde, schneller Feedback-Loop), dann Apple. 36.8.2 Vor Apple-Submit Pflicht-Checkliste: Demo-Account in Review-Notes, Privacy-Policy-URL, Privacy-Manifest aktuell, Account-Löschung sichtbar getestet, kein Pricing-UI im Build, Native-Features funktional, Screenshots zeigen ausschließlich tatsächlich vorhandene Funktionen. 36.8.3 Vor Google-Play-Submit: Data-Safety-Form, Account-Löschung in App + externe Lösch-URL, Privacy-Policy-URL, Permissions-Erklärungen. 36.8.4 Reject-Recovery-Playbook nach Apple-Guideline-Nummer (4.2 Minimum-Functionality, 3.1.1 IAP, 4.8 SIWA, 5.1.1 Account-Löschung, 2.1 Login).

36.X Phase 2 / bewusst NICHT in Phase 1

36.X.1 NFC für Zeiterfassung (Tap-to-Clock-In). 36.X.2 Bluetooth für Beacon-basierte Standort-Erkennung (Baustellen-Auto-Check-In). 36.X.3 Geolocation mit User-Consent für Einsatzort-Auto-Tagging. 36.X.4 CodePush / Capacitor Live Updates für Web-Code-Live-Updates ohne App-Store-Roundtrip. 36.X.5 CRDT-basierte Konflikt-Auflösung für Multi-User-Co-Editing. 36.X.6 Erweiterte Offline-Funktionen: CRM-Offline-Suche, Inbox-Cache, Booking-Bestätigungen, Lead-Bearbeitung. 36.X.7 Silent-Push-Capability für Hintergrund-Sync. 36.X.8 Watch-App-Companion (Apple Watch / Wear OS). 36.X.9 Mikrofon-Permission für Voice-Notes / Diktier-Funktion. 36.X.10 Tablet-spezifische UI-Optimierung (Side-by-Side-Layout im Büro-Modus).

36.Y Klartext-Fehlertexte (Beispiele)

36.Y.1 Push-Permission verweigert: „Push ist auf diesem Gerät deaktiviert. Du verpasst möglicherweise wichtige Updates. [Geräte-Einstellungen]" 36.Y.2 Face-ID-Fehler: „Face-ID nicht erkannt, bitte erneut versuchen oder Passwort eingeben." 36.Y.3 3x Biometrie-Fehlschlag: „Face-ID temporär gesperrt. Bitte mit Passwort anmelden." 36.Y.4 Hardware nicht da: „Dieses Gerät unterstützt kein Face-ID/Touch-ID." 36.Y.5 Kamera verweigert: „Kamera-Zugriff verweigert. [Geräte-Einstellungen öffnen]" 36.Y.6 Offline-Banner: „Du bist offline, gespeicherte Änderungen werden später hochgeladen." 36.Y.7 Sync-Erfolg: „Alle 7 Änderungen wurden synchronisiert." 36.Y.8 Sync-Fehler: „2 Änderungen konnten nicht hochgeladen werden. [Details]" 36.Y.9 Warteschlange voll: „Lokale Warteschlange voll (1.000 Einträge), bitte mit Internet verbinden." 36.Y.10 Foto-Speicher voll: „Foto-Speicher voll (500 MB), bitte Sync starten oder Fotos später aufnehmen." 36.Y.11 Force-Update: „Bitte aktualisiere die HiveGrid-App, diese Version wird nicht mehr unterstützt. [App-Store]" 36.Y.12 Apple-Compliance bei Feature-Block: „Diese Funktion ist im Cloud+-Plan verfügbar. Bitte Workspace-Admin kontaktieren oder am Computer aktivieren."

Modul 38: Help-Center (öffentlich)

Was es tut: Eine öffentlich erreichbare Hilfeseite mit Erste-Schritte-Artikeln, Setup-Anleitungen und FAQ. Nicht zu verwechseln mit einer internen Wissens-Datenbank des Mandanten, dieses Help-Center gehört HiveGrid und ist für alle User gleich.

Warum es wichtig ist: Senkt die Support-Last und gibt Mitarbeitern und Mandanten-Admins Selbsthilfe-Inhalte. Auch SEO-relevant. Phase 1 bewusst minimal.

38.1 Öffentliche Markdown-Artikel

38.1.1 Inhalte werden als Markdown-Dateien im Repository gepflegt, nicht in einer Datenbank. Pflege erfolgt über Git-PRs durch das Plattform-Team. Keine Editor-UI in Phase 1. 38.1.2 Verzeichnis-Struktur pro Sprache und pro Kategorie: - content/help/de/erste-schritte/, content/help/de/vertrieb/, content/help/de/integrationen/ etc. - Pro Kategorie ein Metadaten-File mit Label, Beschreibung, Icon, Sortier-Reihenfolge. 38.1.3 Pflicht-Felder pro Artikel-Frontmatter: Slug, Title, Kategorie, Sortier-Reihenfolge, Beschreibung, Datum letzte Aktualisierung. Optional: verwandte Artikel, Keywords, Veraltet-Marker, Redirect-Ziel. 38.1.4 Markdown-Body mit Standard-Formatierung: Überschriften (H2–H4), Listen, Code-Blöcke, Tabellen, Bilder, Links, Hinweis-Blocks (Info/Warnung). 38.1.5 Build-Schritt erzeugt: Volltext-Index, Kategorien-Manifest, Sitemap. Build-Validierung prüft alle Kategorie-Referenzen und alle Verlinkungen, bei Fehler bricht der Build ab. 38.1.6 Routen: - app.hivegrid.de/help/ → Sprach-Redirect (Phase 1 immer auf /de/). - app.hivegrid.de/help/de/ → Help-Home mit Kategorien-Übersicht und zentraler Suche. - app.hivegrid.de/help/de/{kategorie}/ → Liste der Artikel in dieser Kategorie. - app.hivegrid.de/help/de/{kategorie}/{slug} → Einzel-Artikel. - app.hivegrid.de/help/de/search?q=... → Such-Ergebnisse. - app.hivegrid.de/help/sitemap.xml für SEO. 38.1.7 Öffentlich zugänglich, kein Login erforderlich, kein Mandanten-Kontext. 38.1.8 SEO: statisches Rendering mit langen Cache-Headern, pro Artikel Title und Description aus Frontmatter, Open-Graph-Tags, Canonical-URL. 38.1.9 In jedem App-Bereich kann ein optionales Hilfe-Icon mit Tiefenroute auf den passenden Help-Center-Artikel verlinken (Mapping pro Route konfiguriert). 38.1.10 Suche mit Title-Match zuerst, dann Description, Keywords, Body. Treffer-Snippet mit Highlight. Empty-State: „Nichts gefunden zu '{Query}'. Schreib uns: support@hivegrid.de" 38.1.11 Artikel-Detail bietet: Titel, Beschreibung, letzte-Aktualisierung-Datum, Markdown-Body, Inhaltsverzeichnis aus H2-Überschriften, verwandte Artikel als Liste am Ende, optionales „War dieser Artikel hilfreich?"-Feedback (Daumen hoch/runter, anonym). 38.1.12 Veraltete Artikel: Banner „Dieser Artikel ist veraltet, siehe stattdessen [neuer Link]" 38.1.13 404 (Slug nicht gefunden): „Diesen Artikel gibt's nicht mehr. Vielleicht hilft die Suche?"

38.2 Phase 1: 10–20 Artikel

38.2.1 Initial-Inventar (konkrete Liste mit Plattform-Team beim Bau finalisiert): - Erste Schritte: Willkommen, Tenant einrichten, Erste Mitarbeiter einladen, Magic-Link-Login-FAQ. - Vertrieb: Kontakte und Firmen, Lead-Inbox-Workflow, Sales-Pipeline-Grundlagen. - Aufträge: Projekt anlegen, Plantafel nutzen, Acceptance-Protokoll-Anleitung. - Mitarbeiter: HR-Hub-Übersicht, Krankmeldung/Urlaubsantrag stellen. - Integrationen: KWP-Setup, Google-Kalender verbinden, AirCall-Setup, E-Mail-Integration (Gmail/Outlook). - Mobile: Mobile-App-Setup, Offline-Modus auf Baustelle. - Abrechnung: Legacy-Provider-Setup, Plan wechseln, Rechnungen einsehen. - Tutorials: Form-Builder-Tutorial, Automation-Builder-Tutorial. 38.2.2 Phase 1 nur Deutsch. Andere Sprachen: 404 mit Klartext-Banner „Englischsprachige Hilfe ist in Vorbereitung. Hier ist die deutsche Version." plus automatischer Redirect auf DE. 38.2.3 Performance Phase 1: Client-side Volltext-Index (FlexSearch oder ähnlich, ca. 50 KB für 20 Artikel) ODER Server-side Postgres-FTS, Tooling-Wahl beim Bau.

38.X Phase 2 / spätere Features

38.X.1 DB-getriebene Pflege durch Plattform-Admin mit Editor-UI auf admin.hivegrid.de. 38.X.2 Mehrsprachigkeit: EN/TR/PL via DeepL-Pipeline aus DE-Quelltext, manuell verifiziert. 38.X.3 KI-gestützte Artikel-Suche (Help-Center-Inhalte als Embeddings-Korpus für KI-Assistent in der App). 38.X.4 View-Counts und Helpful-Votes-Statistik für das Plattform-Team. 38.X.5 Versionierung mit Sicht auf alte Artikel-Versionen bei Deprecation. 38.X.6 Kontextuelle Inline-Hilfe, Side-Panel direkt in der App statt Tab-Wechsel. 38.X.7 Video-Tutorials einbettbar (YouTube/Loom). 38.X.8 „Was ist neu?"-Changelog-Feed auf Help-Home.

38.Y Klartext-Fehlertexte (Beispiele)

38.Y.1 Sprache nicht da: „Englischsprachige Hilfe ist in Vorbereitung. Hier ist die deutsche Version." + Auto-Redirect. 38.Y.2 Empty-Search: „Nichts gefunden zu '{Query}'. Probier andere Begriffe, oder schreib uns direkt an support@hivegrid.de." 38.Y.3 Artikel 404: „Diese Hilfe-Seite gibt's nicht mehr. [Zur Übersicht] oder [Suche starten]."

Modul 39: Help-Desk / Support

Was es tut: Ein einfaches In-App-„Problem melden"-Widget plus eine Support-E-Mail-Adresse, dahinter ein simples Ticket-System für das Plattform-Team. Kein Live-Chat, kein User-facing-Status-Tracking, Phase 1 bewusst klein.

Warum es wichtig ist: Die niedrige Hürde, „Wir hören zu" zu signalisieren, ist Teil der Anti-Agentur-Positionierung. Mandanten-User sollen Probleme schnell melden können, das Plattform-Team braucht eine sortierbare Eingangs-Liste.

39.1 In-App-Feedback-Widget

39.1.1 „Problem melden"-Trigger ist von jeder Mandanten-Route aus erreichbar (Designer entscheidet die genaue Platzierung, global in der Top-Bar, als Floating-Button oder ähnlich). 39.1.2 Im öffentlichen Help-Center gibt es einen identischen Trigger, der zu mailto:support@hivegrid.de verlinkt (kein Login → kein Mandanten-Kontext für ein Ticket). 39.1.3 Eingabe-Modal mit: - Hinweis-Text „Was hakt? Wir lesen jedes Feedback persönlich." - Anzeige der aktuellen Route, Transparenz, dass wir das mit-erfassen. - DSGVO-Hinweis, dass Browser-Info und App-Version mitgeschickt werden. - Mehrzeiliges Eingabefeld (Pflicht, mindestens 10 Zeichen). - Anhang-Upload (Drag&Drop und Datei-Wähler), max. 5 Dateien zu je 10 MB. Erlaubte Formate: PNG, JPG, WEBP, PDF. - „Screenshot der aktuellen Seite anhängen"-Funktion (One-Click, optional, mit User-Bestätigung). - Senden-Button (deaktiviert bis ≥ 10 Zeichen). 39.1.4 Bei Senden automatisch erfasst: Mandant, User, aktuelle Route (ohne sensible Query-Parameter), Browser-Info (User-Agent, Viewport, Sprache, Timezone), App-Version, Zeitstempel. 39.1.5 Klartext bei Erfolg: „Danke. Wir haben dein Feedback bekommen und melden uns falls nötig." 39.1.6 Klartext bei Fehler: „Senden hat nicht geklappt, du kannst uns auch direkt schreiben: support@hivegrid.de" 39.1.7 Rate-Limit: max. 10 Submissions pro User pro Stunde. Body max. 10.000 Zeichen. 39.1.8 Jeder eingeloggte Mandanten-User kann Feedback senden, keine spezielle Berechtigung. „Problem melden" ist basale Funktion, kein Premium-Feature.

39.2 Email-basiertes Ticket-System Phase 1

39.2.1 Inbound-Mailbox: support@hivegrid.de läuft auf Google Workspace oder Scaleway-Mail. 39.2.2 Phase 1: das Plattform-Team liest die Mailbox außerhalb der App (Gmail-Web). Keine eigene Mail-Sync-Implementierung in HiveGrid für die Support-Mailbox. 39.2.3 Im Plattform-Admin-Bereich gibt es einen Direkt-Link zur externen Mailbox plus Klartext-Hinweis „Externe Support-Mailbox via Google Workspace". 39.2.4 Keine automatische Verknüpfung Mail ↔ Feedback in Phase 1, manuelle Pflege. 39.2.5 In-App-Feedback-Submissions landen im Plattform-Admin-Bereich „Feedback / Support": - Liste mit Eingangs-Datum, Mandant, User, ersten 100 Zeichen Body, Anzahl Anhänge, Route, Status, zugewiesener Bearbeiter. - Filter nach Status (offen / in Bearbeitung / gelöst / wontfix), Mandant, Bearbeiter, Zeitraum. - Volltext-Suche über Body + Mandanten-Name + User-Name. - Bulk-Status-Wechsel und Bulk-Zuweisung. - CSV-Export der gefilterten Auswahl. 39.2.6 Detail-Ansicht pro Feedback: - Vollständiger Body, Anhänge mit Vorschau. - Mandanten-Block mit Plan, Status, Direktlink ins Mandanten-Admin. - User-Block mit Rolle, Direktlink ins Mandanten-Admin. - Route klickbar (für Plattform-Admin mit Impersonation-Recht). - Browser-Info ausklappbar. - Inline-Edit für Status und Bearbeiter. - Interne Notizen (Markdown, nur Plattform-Admin-sichtbar). - Aktivitäts-Log: alle Status-Wechsel, Bearbeiter-Wechsel, Notizen-Änderungen. - Hard-Delete nur in Ausnahmefällen mit Klartext-Warnung. 39.2.7 Status-Lebenszyklus: offen → in Bearbeitung → gelöst oder wontfix; Re-Open jederzeit möglich. 39.2.8 Phase 1: KEINE Notifications zurück an den Mandanten-User über Status-Änderungen. 39.2.9 Berechtigungen Plattform-Admin-Seite: spezielle Plattform-Admin-Rechte für Lesen, Schreiben, Löschen. 39.2.10 Anhänge nutzen die zentrale Datei-Infrastruktur, Storage-Pfad pro Feedback im Mandanten-Storage.

39.X Phase 2 / spätere Features

39.X.1 In-App-Live-Chat mit Support (Intercom-/Crisp-Style oder Eigen-Implementierung). 39.X.2 Vollständiges Ticket-System mit Status-Tracking und Notifications zurück an User. 39.X.3 User-facing-Status-Page im Mandanten: Liste der eigenen Feedbacks mit Status, kann antworten. 39.X.4 NPS-Surveys (1×/Quartal, anonymisiert). 39.X.5 CSAT-Tracking (1–5 Sterne nach Resolution). 39.X.6 Support-Mailbox-Sync direkt in HiveGrid über die E-Mail-Integration (Modul 9). 39.X.7 Auto-Triage durch KI: Klassifikation Bug / Feature-Request / Frage / Beschwerde, Bearbeiter-Vorschlag. 39.X.8 Feedback-Voting: ähnliche Feedbacks zusammenfassen, andere Mandanten können „+1" geben (Public-Roadmap-Feel). 39.X.9 Integration mit Bug-Tracker (Linear / Jira / GitHub-Issues). 39.X.10 Slack-Notification an Plattform-Team-Channel bei neuem Feedback.

39.Y Klartext-Fehlertexte (Beispiele)

39.Y.1 Beschreibung zu kurz: „Bitte mindestens 10 Zeichen, je mehr Details, desto schneller können wir helfen." 39.Y.2 Anhang zu groß: „Datei zu groß (max. 10 MB). Beschneide sie oder lass sie weg, wir können trotzdem helfen." 39.Y.3 Senden gescheitert: „Senden hat nicht geklappt, Internet-Verbindung prüfen oder direkt an support@hivegrid.de mailen." 39.Y.4 Rate-Limit: „Du hast schon einige Meldungen in kurzer Zeit gesendet. Bitte warte kurz oder schreib uns direkt." 39.Y.5 Mandant pausiert: „Dein Workspace ist derzeit pausiert. Schreib uns direkt: support@hivegrid.de" 39.Y.6 Tenant inzwischen gelöscht (Plattform-Admin-Sicht): „Dieser Tenant wurde inzwischen gelöscht, Daten zu User/Tenant nur noch eingeschränkt verfügbar."

Anhang

H.1 Geparkte Themen

Diese Themen sind bewusst nicht Teil dieses Pflichtenhefts. Sie werden in eigenen, abgegrenzten Runden geklärt, bevor die Implementierung begonnen oder abgeschlossen wird.

H.1.1 Pricing-Modell

H.1.1.1 Status: unbestimmt. Konkrete Preise pro Plan, Trigger-Volumen-Limits und Setup-Fees stehen noch nicht fest. H.1.1.2 Worauf das Pflichtenheft schon vorbereitet ist: - Drei Plan-Stufen werden technisch bedacht (Cloud, Cloud+, Enterprise, siehe Modul 28). - Seat-Modell mit Unterscheidung zwischen Büro- und Monteur-Sitzplätzen ist im Auth-Modul (M27) und Subscription-Modul (M28) verankert. - Trigger-Volumen-Metering pro Mandant ist im Automation-Modul (M17.L) gebaut, die konkreten Limits werden später per Konfiguration eingespielt. - Trial-Phase und Read-Only-Downgrade bei Nichtzahlung sind funktional in M28 vorgesehen. H.1.1.3 Was zu klären ist (separater Workflow): - Konkrete Preise je Plan und Seat-Typ. - Setup-Fee ja/nein, Höhe. - Trigger-Volumen-Limits pro Plan (1.000/h? 10.000/h?). - Self-Service-Sales vs. Demo-Termin-Pflicht ab welchem Plan. - Discount-Logik für Jahres-Bezahlung, Multi-Year-Verträge.

H.1.2 Migration aus HubSpot, Quiply und KWP

H.1.2.1 Status: geparkt für eigene Runde nach Sign-off des Pflichtenhefts. H.1.2.2 Worauf das Pflichtenheft schon vorbereitet ist: - CSV-Import-Pfad für Kontakte, Firmen, Deals (M01, M03) ist als Phase-1-Bestandteil vorgesehen. - Apps-Engine (M33a) kann Adapter zu HubSpot/Quiply als spätere Implementierungen aufnehmen. H.1.2.3 Was zu klären ist (separater Workflow): - Welche Daten werden aus HubSpot mitgenommen, welche bleiben dort liegen? - Wie werden Quiply-Mitarbeiter-Daten überführt (insb. Dokumente, Lohn-Daten)? - Welche KWP-Bestände werden initial in die HiveGrid-CRM-Welt gespiegelt? - Migration-Termine vs. Live-Betrieb-Übergang (Cut-Over-Plan).

H.1.3 KWP-Native-Integration nach Geschäftsführer-Termin

H.1.3.1 Status: offen. Termin mit KWP-Geschäftsführer geplant. Ergebnis kann Modul 19 vereinfachen (oder M8, Rechnungs-UI, neu evaluieren). H.1.3.2 Vorgehen: - Termin abwarten, Aussage zu offizieller API/Datenbank-Anbindung dokumentieren. - Modul 19 ggf. nachschärfen (z. B. Wegfall des Schema-Drift-Sentinels, wenn API-Kontrakt entsteht). - Ggf. Modul 8 (eigene Rechnungs-UI) aus Phase 2 vorziehen oder dauerhaft streichen.

H.1.4 Sales-Flow Self-Service vs. Demo-Pflicht

H.1.4.1 Status: geparkt. Betrifft Marketing-Webseite und Onboarding (M29). H.1.4.2 Worauf das Pflichtenheft vorbereitet ist: Onboarding-Modul kann beide Flows bedienen.

H.2 Verifikations-Workflow für Noah

H.2.1 Wann ist eine Sektion „verifiziert"?

H.2.1.1 Verifiziert = Noah hat die Sektion gelesen, alle Punkte einzeln geprüft und entweder - OK vermerkt (kein Änderungsbedarf), oder - Korrektur-Vorschlag als Klartext-Anmerkung am betroffenen Punkt formuliert.

H.2.1.2 Nicht verifiziert = Sektion noch nicht durchgegangen, oder offene Anmerkungen sind nicht aufgelöst.

H.2.2 Empfohlene Reihenfolge

Das Pflichtenheft ist nach Implementierungs-Blöcken sortiert. Für die Verifikation empfiehlt sich aber eine andere Reihenfolge, die der Geerkens-Workflows folgt:

H.2.2.1 Termin 1 (60-90 Min): Vertrieb und Auftrag: Block 3 (Sales-Pipeline, Auftrags-Pipeline, Tasks) plus Modul 1, 2 (CRM, Lead-Inbox) aus Block 2. Hier sitzt der Kern, hier sollte Noah am intensivsten korrigieren. H.2.2.2 Termin 2 (60-90 Min): USP-Säulen: Block 4 (Apps-Engine, Automation, KI, KWP-Integration). Hier prüft Noah, ob die Wenn-Dann-Vorstellungen seinem Tagesgeschäft entsprechen. H.2.2.3 Termin 3 (60 Min): Kommunikation und Mitarbeiter-Plattform: Block 5 (Email, Marketing, Telefonie, Chat, Push, Kalender) plus Modul 14 (HR-Hub) aus Block 6. H.2.2.4 Termin 4 (60 Min): Spezialfälle und Außenseite: Rest von Block 6 (Form-Builder, Booking, Angebot, Customer-Portal, Dashboard) plus Block 7 (Audit, Subscription, Onboarding, API, DSGVO, Mobile, Help-Center, Help-Desk). H.2.2.5 Termin 5 (60 Min): Plattform-Fundament und Architektur: Block 1 (Auth, i18n, Branding, Feature-Flags, Plattform-Admin) plus Architektur-Vorschriften (Kapitel A). Hier schaut Noah, ob die Bauprinzipien zu seinem Verständnis passen, viele Punkte hier sind mehr „Vertrauen statt Detail-Korrektur".

H.2.3 Anmerkungs-Format

Korrektur-Vorschläge bitte direkt am Punkt mit folgender Form:

M04.6.5  Plantafel-Drag-and-Drop muss nur Wochen, nicht Tage zeigen
         → Korrektur Noah, 12.05.2026: Tage müssen rein, sonst überschneiden
           sich Mehrtages-Einsätze nicht erkennbar.

So bleibt nachvollziehbar, wer wann was geändert hat, ohne dass das Pflichtenheft umstrukturiert werden muss.

H.2.4 Sign-off

H.2.4.1 Sign-off erfolgt pro Modul-Block, sobald alle Anmerkungen aufgelöst sind. Das geht parallel zur Implementierung, Block 1 (Plattform-Fundament) muss vor allen anderen sign-off-fähig sein, weil die anderen darauf aufbauen.

H.2.4.2 Vollständiger Sign-off = alle 7 Blöcke plus Architektur plus Anti-Liste plus Anhang von Noah freigegeben.

H.2.4.3 Nach vollständigem Sign-off: alle weiteren Änderungen über die Change-Request-Liste (siehe A.9).

H.3 Change-Request-Format

Eine Change-Request hat folgende Felder, die ausgefüllt sein müssen, bevor sie Wirkung hat:

Change-Request-Liste wird zentral geführt (Format: einfache Tabelle, z. B. Markdown im Repository oder Notion).

H.4 Verweis auf Detail-Spezifikationen

Dieses Pflichtenheft ist die konsolidierte Klartext-Form. Für jedes Modul gibt es eine technische Detail-Spezifikation mit Datenmodell, exakten Feld-Namen, Permission-IDs und Routen-Pfaden. Die Detail-Specs sind die Vertragsanlage für die technische Umsetzung, nicht für Noah-Review.

H.4.1 Speicherort der Detail-Specs: _bmad-output/specs/M*.md (Markdown) und _bmad-output/specs/pdfs/M*.pdf (PDF).

H.4.2 Master-Scope-Dokument (Brainstorming-Ergebnis mit Leitplanken, Pre-mortem, Edge-Cases): _bmad-output/brainstorming/brainstorming-session-2026-05-07-2206.md.

H.4.3 Schema für die Detail-Specs: _bmad-output/specs/_SCHEMA.md.

H.4.4 Wenn Noah einen Punkt in diesem Pflichtenheft tiefer verstehen will, wird auf die zugehörige Detail-Spec verwiesen, diese liefert das technische Wie zum hier dokumentierten Was.

H.5 Versions-Historie dieses Pflichtenhefts

H.6 Eingearbeitete Anmerkungen aus Noah-Review #1 (2026-05-09)